RE: How to Create an ebXML Order (EDI 850 transaction set)

["Probert, Sue" <Sue.Probert@commerceone.com>]

I agree that it not necessarily important to agree on the exact number of
existing traditional EDI message types. However, it is important to
understand what range of business processes that they cover and to
understand the degree of overlapping that is unfortunately prevalent.

For example how many of the 3,000 suggested message types in existence are,
in fact, purchase orders? how many are transport orders of different types
etc. etc. We certainly do not want to replicate all of these!

One of the earliest decisions taken by the ebXML core components group was
that we did not want to simply replicate EDI in XML. This was agreed by the
group for a number of crucially important reasons including the following:-

a) it is recognised that there is semantic ambiguity at all levels of all
the existing traditional EDI standards despite the good intentions of all of
the expertise that has  contributed to their development over the years.
This is true even of the global standard, UN/EDIFACT and is certainly true
of the many national standards such as X12, Tradacoms etc. and numerous
industry standards and community subsets such as ODETTE/EDIFACT and IATA
PADIS etc. etc. as well. Even a short glimpse at the code lists of any of
these published standards results in immediate evidence of this basic truth.

b) In addition there is the problem of the overlapping between these
existing standards and/or community subsets. In each case we can be sure
that all of the messages types necessary to support basic supply chain data
exchange functionality i.e. the 'buy, ship, pay' scenario are replicated
e.g. purchase order, order response, despatch advice, invoice, payment etc. 

c) XML may well not be the last syntax to come along. 

It was agreed unanimously by the group that, for all the above reasons,
ebXML should rather aim to produce a framework within which common business
process models could be defined and non-ambiguous semantic data definitions
could be collated in a syntax neutral language which can then be implemented
in any past, present or future syntax.

It is very important to realise the breadth and depth of the EDI and
business experience which was behind these decisions. The ebXML core
components membership list includes experts from virtually every relevant
standards body and user group covering both traditional EDI and XML
developments. In fact one of the greatest achievements of the ebXML
initiative has been, in my opinion, to bring together the most impressive
range of expertise that has ever been collected together in one place to
work in these crucial areas. 

In my view, as chair of the UN/EDIFACT implementation harmonisation group
and leader of the harmonisation aspect of the continued ebXML joint
EDIFACT/X12 BP/CC work (JCC), it would be senseless and counter productive
if UBL were not to take full account of the ebXML syntax neutral approach to
defining common business processes and the harmonised set of business
semantic definitions which are needed to support them. This is especially
true as the ebXML work is based on all of our combined past experiences
including the cumulative lessons learnt along the way over the past twenty
years or so.

regards

Sue

Sue Probert
Director, xCBL Unit, Commerce One Labs
Commerce One
Tel: +44 1332 342080
www.commerceone.com


-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: 20 July 2001 03:56
To: mike@rawlinsecconsulting.com
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: How to Create an ebXML Order (EDI 850 transaction set)




Mike Rawlins wrote:

> Correction:  A few folks have bandied about the figure of 3,000+ standard
EDI
> messages.  This is an overstatement by a factor of about 5.   There are
only
> 300+ ANSI X12 transaction sets and a similar number in UN/EDIFACT,
yielding
> about 600.  You only approach 3000 if you include the lesser used
standards such
> as HL7, TRADACOMS, ODETTE, and EIAJ, and count in some of the industry
> implementations of X12 such as UCS, VICS, and WINS.  If you include all of
the
> industry and company specific implementation guides, 3,000 is way too low.
>>>>>>>>>>>>

Mike:

Thanks you for the voice of truth.  I realized this too but I felt it 
was less important to be technically correct at that time becuase there 
was truth to John statement regardless of the actual physical number of 
transactions.  Even at 300,  it is simply beyond the immediate scope of 
the UBL groups work.

John:

Thank you for joining and planning on attending the working group in 
Montreal.

See you all there.

Duane Nickull


> 



------------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org