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

[John Evdemon <jevdemon@vitria.com>]

On Friday, July 13, 2001 12:57 PM Duane Nickull  wrote:
> 
> > opinion) seem to be a logical starting point for this work.  Jon's group
is
> > going to spend a lot of time "re-inventing the wheel" to close the gap
> > between XCBL and the way companies have been conducting e-business
> > for over 20 years.
>
> I don't believe it is as drastic as you make it sound.  
>
How familiar are you with EDI and EDIFACT?  EDI (X12 and EDIFACT) have
defined the metadata (and actual transactions) for over 3,000 standard
business documents while XCBL 3.0 provides 41.  XCBL may, in fact, be the
world's greatest markup "standard" for indirect materials procurement.  It
is not, however, the best starting point for designing markup to support the
direct materials space.

> I am not a Cone cheerleader and xCBL has its' problems however we are 
> using it as a starting point.  
>
Why start with something that contains known flaws?  There are far better
starting points.  I think that the logical starting point is the X12 and
EDIFACT metadata itself, not a significantly smaller subset.   How was this
conclusion reached (and how many of the decision makers were familiar with
the metadata defined by EDI)?  

Note: I am not a sales person - I am merely interested in starting with the
best possible foundation for building messages.  I think that the X12 and
EDIFACT metadata provides an obvious starting point - if only because of its
breadth, maturity and world-wide acceptance when compared to XCBL.  

> We may decide to totally disregard it and start 
> from scratch.   
>
Both approaches will result in the significant duplication of work that has
already been completed.  

> xCBL has a fairly wide level of adoption among industry
> groups and there is a lot fo feedback that we can use.
> 
Are any of these groups using XCBL (alone) for direct materials procurement?
Are you implying that XCBL has a larger user/experience base than X12 and
EDIFACT?

While I realize that not everyone uses EDI, the metadata associated with EDI
is quite capable of describing most (if not all) transactions used by most
businesses.  I'm not sure if I could say the same about XCBL.

> More like 5 gallons of water into a 1.97 bushel potato sack.  The world
> is truly broken <sigh>.
> 
A sad but true fact that ebXML (and any other initiative) will be unable to
correct.  Companies that adopt ebXML will continue to develop and use their
own (potentially incompatible) implementation guidelines - much like they do
with EDI today.

> Simply put - one to one mappings ususally don't work due to a complete
> mismatch at the document level.  
>
True, unless you use the XEDI approach.  XEDI supports a direct one to one
mapping for any transaction, any version of X12 and EDIFACT.  There is no
mismatch at the document level.  There is no dilution or loss of data.

> How can one map to an element in a
> target document when the information was not present in the original
> document?  
>
Or map something that does not exist in the target (especially when moving
from EDI to markup that doesn't support direct materials).   

> I have ideas for this which involve "installing" core
> components on the source machine.  The CC's can read for information or
> take certain actions when needed such as promting a user for input.  It
> is a lot more complex however my tests indicate that it will work.
> 
I'm a bit skeptical about this - I would expect the transformation to be
strictly a machine to machine process.  Prompting a user to supply missing
information for each transaction is not practical for an organization that
may be processing hundreds of thousands transactions per day.    

> The template is built by hand from our template editor (GoXML
> Transform).  A free download is available (time limited) at
> http://www.xmlglobal.com/prod/transform but I would wait about two weeks
> for the newer version.
> 
> We build the tamplate by performing lookups into our ebXML Registry to
> examine the core components.  The CC's contain information to help in
> mapping to the target format.
> 
This sounds very thorough, but the XEDI approach provides EDI to XML (and
XML to EDI) support for all transactions, all versions of EDIFACT and X12
"out of the box" (no additional development required).  

I am assuming (hopeful?) that CC's will leverage the metadata supplied by
the EDIFACT and X12 standards (otherwise we are once again back to designing
wheels).  

<!-- portions of Duane's message removed for readability -->
> 
> The answers will lie in the development of an ebXML compliant business
> language.  Other languages might then follow suite and adjust their
> content a bit to be compatible while still meeting businessneeds.
> 

Promoting XCBL as the starting point seems somewhat irrational when you
consider the facts: 
	
XCBL supports 41 business documents that use information models, element and
attribute names that were developed by CommerceOne and, with CBL 3.0, SAP.  

XEDI supports over 3,000 business documents that use information models,
element and attribute names derived directly from existing global e-business
standards (developed over many years by international standards bodies
including, but not limited to, ANSI, and the UN).  

The information models used by XCBL were first introduced in 1997.  

EDI has been evolving under the watchful gaze of global standards bodies
since 1948 (the infamous Berlin Airlift) - the wealth of metadata that has
been developed is capable of describing most (if not all) business
transactions used by the vast majority of businesses today.  XEDI uses this
metadata to generate XML-based information models (DTDs and Schema).  The
XEDI approach can represent any X12 or EDIFACT transaction (any version) in
an XML format (with no semantic gaps - all EDI metadata is preserved).

Which approach seems the most logical to use as a starting point?  

I would think that the answer should be fairly obvious but, surprisingly, is
not (possibly due to a lack of experience or understanding of EDI?).   

Why are we so ready to abandon one group of three letters (EDI) for another
(XML)?  EDI is more than VANs and cryptic syntax - it provides decades of
metadata standards from global standards bodies.  Abandoning this experience
for a recently developed makeup language would be a tremendous mistake.

> BTW - there are a lot larger problems too than you describe.  It is a
> headache.
> 
Agreed - we should minimize the potential headaches by building on a more
solid (read: more thorough and mature) foundation.