RE: DRAF RE: How to Create an ebXML Order (EDI 850 transaction se t)

[John Evdemon <jevdemon@vitria.com>]

On Friday, July 13, 2001 8:29 PM James Bryce Clark  wrote:
> 
> The existence of 3100+ X12 documents is not something to brag
> about.   

Since organizations have been working to XML-enable EDI since 1997 (or
thereabouts) and have (to date) been unsuccessful, I think it IS something
worth bragging about.  However, in the interests of avoiding sales pitch,
I'll try to keep my bragging to a minimum.  (Apologies in advance if I
neglected to do so.)

I'm just trying to make a fairly obvious point: the metadata used by EDI is
far more mature and far more widely used than the proposed starting point.

> Unfortunately, they represent far fewer than 3100 distinct types
> of transaction.   

Perhaps not, but I am fairly certain that they represent far more than 41
distinct types of transaction.  Regardless of the number of transactions
supported, ebXML must provide support for EDI - I'm trying to ensure this is
done as painlessly as possible.

> Since 1948, it appears that no-one has said, "No, candy
> cane industry, you should not create a new doc type, you should adapt this
> one from the lollipop industry that does the same darn thing."

What organization do you propose makes that decision and how could it
possibly be enforced?  Companies will continue to conduct business in ways
that help them gain strategic advantage within their own industries
(regardless of the syntax used to represent the actual transactions).

> A useful taxonomy should recognize and leverage similarities in economic
> structures across industry boundaries.  It is essential to reuse, to EAI
> integration, and to widespread networked resource discovery.  But
> rationalization of that kind has been resolutely avoided by
> vertically-siloed EDI standards traditions.

Much as I would like to agree (and I do), I expect we will see the same
splintering occur with whatever recommendation comes out of ebXML.  
 
> I can't say whether xCBL is an appropriate starting point.  A better
> approach would have been to set neutral requirements first.  It seems an
> internally consistent or adequately designed starting point.  But I am
glad
> someone is trying.

I agree - trying is a good thing - but trying to do something with an
incomplete set of tools just takes longer.