Re: What do people really expect from ebXML? - the Vision "thing"

[David Lyon <djlyon@one.net.au>]

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 <wkammerer@foresightcorp.com>
To: ebXML Core <ebxml-core@lists.ebxml.org>
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: ebxml-core-request@lists.ebxml.org
>