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

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

John:

I was unaware of the "direct" capabilities of XEDI that you mention, but I
still have some concerns about what XEDI is...

(1) Not everything in the X12 and EDIFACT standards is a "core" construct
that will further the ebXML vision. The Core Components group did a ton of
work identifying the needed semantics as opposed to those that are legacy
bloat, unused, etc. And yet, you seem to be advocating abandoning this work
and simply taking the whole lot on again, a huge job of filtering and
harmonization.  It will be far easier to take a somewhat stripped-down view
of EDI standards semantics, already organized into a component library, and
build them up to be what they need to be in conjunction with the JCC work.
Hence, xCBL.

Also, it is somewhat worrisome that using XEDI would become a
so-far-unresolved discussion about whether or not X12 or EDIFACT was
"better". They have their differences, and that is one set of arguments that
I really don't want to inherit when I'm trying to get a business vocabulary
deployed quickly. Despite the harmonization efforts to date, they have
different syntactic and semantic structures. In building xCBL, we had to do
a lot of harmonization work around things such as code lists, and this was a
non-trivial effort, even when we had subsetted which code-lists would be
used. In many critical areas, xCBL has already performed this harmonization,
generally by identifying and removing overlap to the extent possible, but it
uses codes a lot less than either X12 or EDIFACT.

(2) Because XEDI is modelling constructs designed to be expressed in EDI
syntax, it sacrifices much of the power of XML schema languages: for
example, local renaming versus typing (even with a "segment_DTM" element, I
still have a child giving me full semantic qualification in the form of a
code. Far better to have the full, local semantic qualifier at the top level
when developing with tree-based/object-based technology such as current XML
tools. Encapsulation is a standard part of OO, and yet you have modelled it
out of the picture!) The way XEDI models this stuff, you have thrown away
the benefits of using easy things like XPath and XSL by requiring that
everything be qualified by it's children, with the efect of multiplying
lines of code in an XSL stylesheet by the number of possible qualifying
codes. Ow. (Not impossible, but difficult and unneccessary.) xCBL, being
written natively in an XML schema language, does the correct kind of
encapsulation while still retaining the needed type information.

(3) The management of a core library - particularly when you are dealing
with things like managing extensions for processing at run-time - is very
tricky, especially when you're dealing with XML schema, as opposed to DTDs.
xCBL has benefitted from looking at how this is done with EDIFACT, and UBL
can no doubt improve this further. I feel that ultimately xCBL is the best
example we have of an XML-schema-based vocabulary that addresses not just
the issues of data modelling, but the management and coordination aspects of
using XML schemas. No-one else has as much experience doing this, and it is
reflected in the way the componentization is done. Historically, the model
used was EDIFACT, modified to handle many of the new issues brought to the
table by the use of XML schemas. XEDI doesn't have this history - it is a
simple, DTD-based reflection of what is in an EDI vocabulary. Whie this is a
good base, it's not enough, and not what xCBL has to offer.

I guess I simply don't agree with you: I feel like many aspects of typical
XML libraries are evident in xCBL but are lacking in XEDI, even simple
things like having intuitive tag names to people who are not already EDI
experts (albeit these will, in UBL, change to reflect the ebXML naming
conventions). I am, no doubt, prejudiced, but then, so are you, so that's
pretty much equal. What I will say is that I have yet to see you present a
compelling argument for using XEDI as a base vocabulary for doing UBL. I do
see XEDI as a useful part of a transformation solution, and that is a
non-trivial thing. But I don't buy that it is a better place to start than
xCBL, if only because it does nothing but inherit it's good properties from
EDIFACT and X12, which are things we've already taken advantage of in the
ebXML work. xCBL can offer a little bit more than that, since it brings some
others considerations around schema management and XML design to the table.

No doubt we will have a chance to continue the discussion...

Cheers,

Arofan Gregory


-----Original Message-----
From: John Evdemon [mailto:jevdemon@vitria.com]
Sent: Thursday, July 19, 2001 10:59 AM
To: Gregory, Arofan; 'Welsh, David'; 'Duane Nickull';
ebxml-dev@lists.ebxml.org
Cc: Kevin Kail; James Blakeney
Subject: RE: How to Create an ebXML Order (EDI 850 transaction set)


On Tuesday, July 17, 2001 5:31 PM Gregory, Arofan  wrote:
> 
> Let's say that I have a "tax" section in a business message, and I am
> required to supply either a simple VAT tax amount OR a tax rate, a tax
> amount, and a tax type identifier.
> 
> I can model that as follows:
> 
> <!element Tax (VAT | (TaxRate, TaxAmount, TaxTypeIdentifier)>
> 
> Now, it is perfectly conceivable that I can express the same information
in
> an EDI message, and document these dependencies in an implementation
> guide.
> I can even write the application code to make sure that when I get that
> message, it will check to make sure that these business rules are
followed.
> 
> But, what I cannot do with XEDI is have a generic XML parser tell me that
> the message is invalid, because of it's built-in enforcement of the
business
> logic ("business semantics") encoded in the DTD:
> 
This is a gross misrepresentation of the capabilities of XEDI.  XEDI can use
ANY XML parser to enforce the structure and semantics of the message.  You
are only explaining the "indirect" approach which only enforces structure,
not semantics (see my previous message for an explanation of the
difference).  Most of our clients use the "direct" approach, allowing them
to validate structure and semantics with any "generic" XML parser.

> If I have:
> <Tax>
> 	<VAT>3500</VAT>
> 	<TaxType>ExportTarriff</TaxType>
> </Tax>
> 
> in my XML message, this is gibberish: I am giving an amount of VAT, and
> then
> telling you that it is an export tarriff, which it is not. There is an
> internal inconsistency in my message. A generic XML parser can enforce the
> simple business logic described above (the semantic content of my data
> structure) because I modelled it into the DTD. I get an error, explaining
> that I cannot have *both* a VAT element and a TaxType element, which is
> indeed the source of the ambiguity here.

This is an interesting (if overly simple) example.  Listed below is a
portion of a Value Added Tax Declaration Message.   As you can see, the
information model can be used to validate both the structure and semantics
of the message (despite your claim to the contrary).  Also note that the
element names comply with global standard e-business naming conventions.
Each element includes attributes containing metadata associated with the
standard (enabling both EDI and non-EDI users to parse and understand the
markup).  

<!ELEMENT Transaction_VATDEC ( Segment_UNB, Segment_UNG?, Segment_UNH,
Segment_BGM, Segment_DTM?, Segment_LOC?, Loop_NAD+, Loop_AUT?, Segment_UNT,
Segment_UNE?, Segment_UNZ)> 
<!ATTLIST Transaction_VATDEC desc CDATA #FIXED "Value added tax message"
version CDATA #FIXED "D99B">

(Note: the Value Added Tax Declaration Message is one of several thousand
global standard e-business messages that are not supported by xCBL.)

> 
> XEDI does not let me do this: I need an application that understands the
> relationships between the various segments and values as made explicit
> only
> in my implementation guide. Consequently, I have to buy a validator or
write
> the code to enforce these business rules.
> 
Wrong again.  The portion of the DTD listed above can be used by any
"generic" XML parser to validate a Value Added Tax Declaration Message.   We
have DTDs/Schema available to validate the structure and semantics of any
standard e-business transaction with a "generic" parser.  There is no
requirement to buy a proprietary validator or any additional software - any
validating XML parser will work.

> What the XEDI DTD describes are the *structural* components of an EDI
> message ("segment," "loop"), and the XML parser does structural validation
> on the message for me. (It can tell me if I am missing a "segment", but it
> can't tell me which segment I am missing.)
>
Wrong.  See my previous message explaining the differences between the
"direct" and "indirect" approach.  You are describing the "indirect"
approach (which only validates structure).  Again, see my previous email
that explains the differences between the two approaches.  The "direct"
approach supports both structural and semantic validation.
 
> This is the primary difference between a XEDI approach and the type of
> standard XML approach used in xCBL and many other XML busines
> vocabularies.
>
Again, you are incorrect.  XEDI is 100% compatible with the validation
approach used by xCBL and other XML business vocabularies.  XEDI validates
both structure and semantics (as should any XML business vocabulary).  

XEDI is also available in DTD and Schema formats - no proprietary XML
development kits, schema mechanisms or parsers are used or required for
validation.

> Structural validation is critical when I am doing transformation - and
XEDI
> gives me this, as well as a consistent XML format that is easier to
process
> than a flat-file. What it doesn't give me is any level of meaningful
> business "semantic" validation: it won't tell me if the message is
> gibberish, or if I have violated the basic business rules on which my
> business application relies.
> 
Again, you are wrong on this assumption.  XEDI provides BOTH structural and
semantic validation of any standard X12 or EDIFACT message (all versions are
supported) using any validating XML parser.  

> The net result is that XEDI is too narrowly focused to be a solid basis
for
> describing the data structures with which we do business. 
>
This statement is absolutely false and, given your familiarity with EDI, a
bit disturbing.  The data structures and metadata used by XEDI are the same
e-business standards that companies have been using for the past several
decades (EDIFACT and X12).  This fact makes XEDI the ideal choice for
describing the data structures with which we do business because the data
structures in XEDI ARE the way companies have done (and will continue to do)
e-business.  

Unlike other markup initiatives, the data structures and metadata used by
XEDI is derived directly from existing global e-business standards.
Leveraging existing standards enables XEDI to support the 3,000+ standard
transactions (and metadata naming standards) that companies have used to
conduct e-business for decades.  

xCBL is incapable of supporting the breadth of standard e-business
transactions provided by X12 and EDIFACT.  Building UBL on top of xCBL will
require duplicating the benefits that the XEDI approach delivers today.  

Any new standard (such as UBL) should leverage, extend and support existing
standards.  X12 and EDIFACT are in far wider use than xCBL - the XEDI
approach enables us to use these standards now (not 1-2 years from now).

> What we want is
> an
> ability to agree on the packages of information needed for certain
> components, and then build applications that can rely on having those sets
> of data present. 
>
Better yet - leverage the existing global e-business standard packages of
information that have been defined and used for the past several decades.
This approach guarantees compatibility with existing e-business
infrastructures and provides a broad, highly mature set of metadata for
defining additional transactions (although the vast majority of e-business
transactions are already available within the X12 and EDIFACT standard).
Why re-invent the wheel?

> XEDI cannot give us this without requiring a separate set
> of code to perform validation that you can get free from any validating
XML
> parser, assuming you have written your DTDS or schemas correctly - that
is,
> to capture the semantic relationships between explicitly labelled pieces
of
> business data.
>
This statement is false - I assume it is because you are (again) unfamiliar
with the XEDI "direct" approach.   XEDI's "direct" approach uses information
models that can be used to validate both structure and semantics with any
validating XML parser (no need for proprietary schemas, development toolkits
or vendor-specific parsers).

> My basic argument is simple: XEDI is a useful tool, but it is the wrong
tool
> for the task at hand. 
>
XEDI can be used to represent any X12 or EDIFACT e-business transaction (any
version) as XML - with no loss of data.  This is most definitely not the
case with xCBL (since the vast majority of global standard e-business
transactions simply aren't available).  This fact hinders xCBL's
qualifications as the basis for UBL because xCBL fails to comply with (or
support) existing global e-business standards.  

I'm sure that xCBL was designed with the best of intentions (since xCBL s
probably one of the best markup initiatives to support the indirect
materials market).  xCBL is not, however, capable of supporting the vast
majority of standard e-business transactions that have been in use for
decades.

> The semantic content found in X12, UN/EDIFACT, and
> other business vocabularies is hugely valuable, but it's up to us to model
> it in a way that gets the most out of XML technology.
> 
XEDI provides BOTH semantic and structural validation with any validating
XML parser.  XEDI also supports all versions of existing global e-business
standards.  

xCBL provides 41 non-standard transactions while XEDI supports over 3000
global standard e-business transactions (all of which preserve the standard
e-business metadata defined and supported over the past several decades).  

The tool of choice for developing UBL should be somewhat obvious when the
facts are known and understood by all participants.