Subject: Re: What do people really expect from ebXML? - CoreComponents-Transactions!
Hello Betty, I think you are right - I am not certain that you can build the components 'bottom up' - just as you need a process model you need a data model built 'top down'. Cheers, Phil ----- Original Message ----- From: "Betty Harvey" <firstname.lastname@example.org> To: "Gregory, Arofan" <email@example.com> Cc: "William J. Kammerer" <firstname.lastname@example.org>; "ebXML Core" <email@example.com> Sent: Thursday, April 26, 2001 1:37 PM Subject: RE: What do people really expect from ebXML? - CoreComponents-Tra nsactions! > > Arofan: > > I realized that messages weren't what CoreComponents were > developing. It was my understanding that we were developing the 'lego > bricks' that the messages could be created. The underlying core > components would be individual legos and these legos could be constructed > to make a core component - or what I think of as an 'information object'. > Information objects can be used to build messages. > > I, personally, have been a bit confused about who is the intended > audience for ebXML. The original audience was for SME's. I believe that > at this point the audience has changed and is software developers. This > isn't a bad thing but ebXML has been marketed as a global standard for > SME's. The intended audience is where the confusion lies. > > Most organizations (especially SME's) buy off-the-shelf software. > Current accounting software provides mechanisms for SME's to interact with > their bank and in some cases customers and vendors. For instance, Intuit > already uses XML for these transactions (BTW, it does concern me that > companies like Intuit who have been doing SGML/XML transactions for years > aren't involved in this effort). It works very well, as long as you are > in a controlled box with 4 sides, a top and a bottom. However, if you try > to go out of the box, this is where the problem begins and extra manpower > (read cost) is needed to drill a hole in the box and push information out. > Most SME's don't care about EDI, don't even know what the acronym stands > for - they just want to do business in the most efficient, economical > manner. > > > Sorry - I digressed! I think at a minimum we need (1) individual > legos - single components; and (2) blocks of legos - common reusable > information objects. > > Betty > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > Betty Harvey | Phone: 410-787-9200 FAX: 9830 > Electronic Commerce Connection, Inc. | > firstname.lastname@example.org | Washington,DC SGML/XML Users Grp > URL: http://www.eccnet.com | http://www.eccnet.com/xmlug/ > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ > > > On Wed, 25 Apr 2001, Gregory, Arofan wrote: > > > Betty: > > > > I believe we spoke about this exact topic in Orlando, and it certainly came > > up again at other times within CC. > > > > I have long believed that we are achieving little if anything without > > defining messages that can be supported and used - built, naturally, of the > > harmonized components that *have* been the focus of this work. After all, > > interoperability in today's technology is generally keyed to the message > > level, and not below, from an application's perspective. (Although low-level > > agreement has it's own set of important benefits). > > > > I also remember being told quite clearly by the ebXML steering committee > > that we would *not* be working on messages in CC. > > > > At the same time, I get the sense that many people agree with us that > > ultimately - and all other good things aside, as I believe the work CC has > > done is both impportant and useful - a group *will* build such messages out > > of the harmonized core components that have been described. > > > > I guess that what I don't know is how the existing ebXML executive will feel > > about that effort. I also hope that we can build only one common purchase > > order, and not several. I can easily see many groups going off to build the > > common message, resulting in the same chaos we have today. It would also be > > a shame to waste the capabilities for handling variation represented by the > > run-time extension capabilities of such technologies as XML Schema. > > > > I guess at this point it's a "wait and see" kind of thing, and I'm sure > > there will be much discussion of this point in Vienna. > > > > Cheers, > > > > Arofan Gregory > > > > > > -----Original Message----- > > From: Betty Harvey [mailto:email@example.com] > > Sent: Wednesday, April 25, 2001 7:59 AM > > To: William J. Kammerer > > Cc: ebXML Core > > Subject: Re: What do people really expect from ebXML? - > > CoreComponents-Transactions! > > > > > > > > William: > > > > Shy! I don't think we have ever met face-to-face but I don't get > > the impression you were ever shy |-). > > > > I have had my head in the trenches lately and haven't had an > > opportunity to read much less communicate my thoughts on ebXML > > initiatives. I have mostly deleted messages. However, that this thread > > does interest me. Some of the groups that I work with are confused about > > how ebXML can help them, if at all. > > > > ebXML, in my mind, has taken on a totally different turn from the > > original concept. When an individual wanting to learn and understand > > ebXML is told to go read the public documents to get an understanding of > > exactly what ebXML is all about, there is something conceptually wrong > > with this approach. For many years I worked in S&E User Support and found > > it totally rude when colleagues would say RTFM. Basically, this is what > > we are saying to individuals wanting to understand ebXML. > > > > There are currently over 20 documents available for public review > > (this > > doesn't include the ones that haven't been approved for public review). > > Is there anyone who has time to sit down an read 20 different documents on > > ebXML and work enough to feed their family? I don't! > > > > David Lyons specifically asked 'where are the messages' in core > > components. In my mind this is the same as asking 'where is the beef'. > > > > It has also been said that the 'world doesn't need another > > purchase order'. No the world needs a 'common' purchase order, as well as > > world peace and a cure for world hunger. ebXML can solve the 'common > > purchase order' but they can't create world peace, as well as a cure for > > world hunger. > > > > After the Orlando meeting, it was my understanding that core > > components would develop a set of core components that could be used in > > 'common messages'. > > > > Just my 2 cents worth. > > > > Betty > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > Betty Harvey | Phone: 410-787-9200 FAX: 9830 > > Electronic Commerce Connection, Inc. | > > firstname.lastname@example.org | Washington,DC SGML/XML Users Grp > > URL: http://www.eccnet.com | http://www.eccnet.com/xmlug/ > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ > > > > On Wed, 25 Apr 2001, William J. Kammerer wrote: > > > > > David Lyon reiterates his demand for XML documents covering the usual, > > > viz., Product Catalogs, Purchase Orders, Invoices/Receipts, Payment > > > Advices, and Statement of Accounts. And just as often, he has been > > > reminded that producing business documents was not within the initial > > > scope of ebXML. As a matter of fact, I remember the pithy quote being > > > bandied about, in the early days of ebXML, to the effect "the World > > > doesn't need another PO." I never really knew what to make of that, but > > > being painfully shy, I didn't dare ask "what the heck does that mean?" > > > > > > It does sound like there will be a long wait for these documents coming > > > out of ebXML - first we have to model the process, then "discover" the > > > core components all the way down to the basic elements, etc. etc. So, > > > if "It's costing [David] money every day that ebXML is not going," I > > > suggest he take a look at the existing B2B libraries such as xCBL, at > > > http://www.xcbl.org/, or OAGIS, at http://www.openapplications.org/. > > > > > > Both xCBL and OAGIS seem to have everything David is looking for, and if > > > my back were against the wall to come up with XML business documents, > > > those are the first two places I'd look. xCBL even says that their > > > versions will be compatible with whatever ebXML comes up with - and > > > assuming a migration path is provided - so using it may provide the path > > > of least resistance and assurance of compatibility. > > > > > > William J. Kammerer > > > FORESIGHT Corp. > > > 4950 Blazer Pkwy. > > > Dublin, OH USA 43017-3305 > > > +1 614 791-1600 > > > > > > Visit FORESIGHT Corp. at http://www.foresightcorp.com/ > > > "accelerating time-to-trade" > > > > > > > > > > > > ------------------------------------------------------------------ > > > To unsubscribe from this elist send a message with the single word > > > "unsubscribe" in the body to: email@example.com > > > > > > > > > ------------------------------------------------------------------ > > To unsubscribe from this elist send a message with the single word > > "unsubscribe" in the body to: firstname.lastname@example.org > > > > ------------------------------------------------------------------ > > To unsubscribe from this elist send a message with the single word > > "unsubscribe" in the body to: email@example.com > > > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: firstname.lastname@example.org >
eList eXpress LLC