People need transactions !
How can ebXML ever work if it doesn't have
I was led to believe that ebXML was all about
defining some standard XML transactions for eb.
What the world expects is some simple XML documents
- Product Catalogs
- Purchase Orders
- Payment Advices
- Statement of Accounts
The work isn't hard. There are hundreds of
different definitions around and thousands of people who will willingly do the
All that is needed is just to choose one simple
set, document it, and go through a revision process just as with EDI. That's
what I've been told ebXML would be doing.
Presently, the problem isn't lack of XML
definitions, it's having a well balanced set.
Operating under the auspices of the United Nations,
and the way that ebXML is marketed, a lot of people with EDI experience have
been given the impression that ebXML will define some XML transactions not
dissimilar to EDI. That is *a very real expectation*.
People really are expecting an XML transaction set
from ebXML. Especially those with an EDI background.
----- Original Message -----
Sent: Tuesday, April 24, 2001 10:36
Subject: RE: What do people really expect
from ebXML? - Core components..
ebXML has never
intended to create transactions as a deliverable. In fact, ebXML does
not even have a requirement to develop the specifications to develop
them. Is this a failure of ebXML - in my opinion yes. Do we
need these documents quickly - yes. Is it best if a single consistent
approach to schema design, naming conventions, use of ancillary W3C
specifications is developed by an international, neutral standards body -
yes. Will we get them quickly - doubtful if after 18 months we still
don't have an agreement on what it is we are developing a process
> -----Original Message-----
From: David Lyon [mailto:firstname.lastname@example.org]
> Sent: Monday, April 23, 2001 11:01 PM
> Subject: Re: What
do people really expect from ebXML? - Core
> We really need some XML specifications for the
> components of ebXML, as
> we have products that we really want to ship later in the
> It appears as
though there are some difficulties in defining the core
> components, although I note there have been some good efforts in
> directory area and so forth.
> If ebXML needs to produce
documentation quickly, then I would suggest
concentrating on the most important things as far as eb is concerned.
> In my opinion, there are
four documents that need to be
> designed, or
> from existing patterns.
> They are:
(1) The Purchase Order
(2) The Invoice / Receipt / ASN
(3) The Payment Advice
(4) The Statement of Account
> With documentation that describes these four documents, a lot
> of pressure on
could be dissapated.
I've seen that we have quite a few people here who are
> sufficiently skilled
> to make a start
on these components. Also, Edifact/X12 could
quite easily be
> stripped to produce a relatively
simple subset. It doesn't need to do
only the basic stuff.
> Forgive my optimism, but we have Customers who really want to
> bash some of
messages around. It's costing me money every day that
> ebXML is not
> going, so if called
upon, I'd certainly be willing to help.
> Take care all
> David Lyon
> To unsubscribe from this elist send a message with the
> "unsubscribe" in the body to: