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

[John Evdemon <jevdemon@vitria.com>]

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.