[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: What do people really expect from ebXML? - the Vision "thing"
William, You have written an excellent summation. For what it is worth, I can now understand the decision not to include transaction definitions due to the timeframe restraints. I'm postulating, not speaking officially for the group, but I would suggest that with a group will and a concerted effort by just a few individuals, that a set of practical ebXML messages could be documentated or sourced by September. If this were to happen, it could mean that a demonstration of ebXML applications might be possible by the end of the year. Once again, I speak only off my own bat, not wishing to place unneccessary pressure on anybody. Were this possible, I wonder how many ebXML participants would put their hands up to some sort of conference/exhibition somewhere if one were to be scheduled towards the end of the year. That would be a showcase of possibly a ebXML Linux wristwatch or ebXML over Bluetooth? or maybe running on PDAs? Are we capable of producing such technology? Once again, I'm only speculating, but I'm pretty sure that a schedule as postulated above would match most peoples expectations. As suggested, I shall take a close look xCBL and the OAGIS messages for my own education. Regards David Lyon ----- Original Message ----- From: William J. Kammerer <firstname.lastname@example.org> To: ebXML Core <email@example.com> Sent: Thursday, April 26, 2001 12:49 PM Subject: Re: What do people really expect from ebXML? - the Vision "thing" > Mike Rawlins is correct when he says ebXML never promised "to deliver > transactions (standard schemas, DTDs)." But I'm surprised Mike thinks > "it is highly unlikely that it is something that ebXML or a *direct* > successor will do." If we actually had the "syntax-neutral" core > components promised by ebXML - the "soul" of transactions and messages - > it would probably be merely a hop, skip and a jump to actual XML schemas > and DTDs. > > The ebXML initiative ends after Vienna, and we have been led to believe > that the Core Component work will continue in the Joint UN/EDIFACT & ASC > X12 Core Component Development Group, led by Mark Crawford of X12. As > Mr. Crawford believes that ebXML [CC] should have had "a requirement to > develop the specifications to develop [transactions]," we might surmise > that ebXML's successor will be more favorably inclined toward that end, > and be - in Arofan Gregory's words - the group that "...*will* build > such messages out of the harmonized core components..." > > Though Mike Rawlins is technically correct when he tells David Lyon that > he "[doesn't] think ebXML is the best venue" for developing XML > business messages, it's simply because the ebXML initiative will end > after Vienna in a few weeks. It doesn't matter what ebXML has > transformed into - or under what name it goes by - but I'm confident X12 > and EWG under Mr. Crawford's leadership will eventually produce not only > "syntax neutral" core components, but the actual "ebXML" business > messages that Mr. Lyon is looking for. > > Mary Kay Blantz has confirmed this direction under the auspices of X12 > and EWG when she asked if there was "Any chance [Lyon] can attend the > X12/EWG meeting in June?" We will be doing exactly what he needs: > designing the basic messages. Mary Kay's warm invitation should have > come with a caveat, though: the X12 meeting will be in St. Louis, but I > suspect Mr. Lyon is in Australia! In the meantime, I do hope David > looks in detail at the xCBL (and even the OAGIS) messages; not only > will he be able to implement and package them up in ebXML's TR&P > Messaging Services, but I'm sure Commerce One will provide a migration > path to the equivalent "ebXML" messages, as they have done for X12. > > Stuart Campbell's kind words are appreciated, but he needn't worry that > I have so much free time. I will make time for an initiative like ebXML > which grabs the imagination, and which could have a positive effect on > globally enabling B2B interoperability. And even though it could remain > unsaid: that which spurs demand for solutions I - and others - have a > desire to satisfy as vendors. > > In order to save some of my free time, I don't bother getting into the > bowels of the ebXML Messaging Services, simply because I am confident > the TR&P team understands the nuances of transport, and will deliver a > standard which can be used for secure, direct exchange of business > payloads. I am satisfied they will eventually get the details right. > Likewise, the Trading Partner team seems to have a handle on CPPs and > CPAs, with a good appreciation of the security and negotiation issues > that will enable open-EDI. And even if the Registry and Repository > Group has had some fitful starts, it looks like we'll finally have > standards for automated "discovery" of (known) trading partners based > on business identifier - an important part of recruitment and engagement > which will liberate us from the stranglehold of proprietary VANs. > > Perhaps the Business Process methodology seems a little heavy-weight > right now, especially considering the demands of the smaller > enterprises. As David Lyon put it: "...most Managers worldwide in SMEs > wll tell you that they know pretty much know all there is to know about > a Purchase Order or an Invoice." I love that line! But BPM is clearly > something larger enterprises will demand for choreographing complex > supply chain interactions, though perhaps not needed by David right now. > > We have reason for great optimism regarding the vision, and even the > work product, of the other areas of ebXML Unfortunately, I haven't > heard the vision articulated - nor, I confess, can I synthesize one > myself - for Core Components. I could settle for, as Mike Rawlins put > it: a "value proposition." In particular, why do we expect the > standards and products built upon the CC specs will result in anything > better than what we have today with EDI? > > It's probably tempting to complain loudly about our mailboxes filling > up, jokingly passing out awards for causing the most number of > unsubscribes, or even psychoanalyzing. But perhaps that energy should > be spent crafting a "vision" thing before we find ourselves in Vienna - > if even it's only "an agreement on what it is we are developing a > process for," as Mr. Crawford reminded us. > > 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: firstname.lastname@example.org >
Powered by eList eXpress LLC