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

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

Folks:

Let me try to explain my point a bit more clearly:

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:

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.

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.

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.) 

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.

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.

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. 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. 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.

My basic argument is simple: XEDI is a useful tool, but it is the wrong tool
for the task at hand. 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.


Cheers,

Arofan Gregory



-----Original Message-----
From: Welsh, David [mailto:David.Welsh@nordstrom.com]
Sent: Tuesday, July 17, 2001 1:06 PM
To: 'Duane Nickull'; ebxml-dev@lists.ebxml.org
Subject: RE: How to Create an ebXML Order (EDI 850 transaction set)


Duane, or maybe Arofan,

I read :
> 
> XEDI has a strength in that it allows easy and complete 
> carriage of existing
> XML standards, and it is an excellent approach for some 
> applications, mostly
> those focusing on transformation, since it has rendered a 
> flat-file format
> into an XML format capable of being subject to XSL 
> transforms, etc. 

Some would say that's just what in practice happens with traditional EDI and
conventional EDI translators today; where in many cases (maybe with all "out
of the box software products") you can't ask an EDI translator for the
business concept of a "PO minimum order quantity for a particular article"
(and if the PO number is valid in say in an in-house ERP system) but you can
ask the software that an EDI segment 'xxx' and data element 'yyy' be filled
or not get's filled somehow. Referencing the use of the phrase 'business
semantics' below; I think.

> Where it
> fails - and the thing that makes it unsuitable for use with 
> most existing
> XML technologies as a basic standard - is that it makes it 
> impossible to
> validate business semantics with an XML parser. 

Please clarify what you mean by "business semantics". It seems a very
heavily loaded term, and I want to understand your point. Maybe a practical
example why xCBL has better 'business semantics' than EDIFACT or X12. 

> All it allows you to
> validate is the structural relationships within the EDI 
> mesage. Compliant
> XML parsers will not tell you whether you have obeyed the 
> semantic rules
> embedded in the schema or DTD, since these are not enforced.
> 

Statement above "Compliant XML parsers will not tell you whether you have
obeyed the semantic rules embedded in the schema or DTD, since these are not
enforced." threw me a curve. Whether you've got an xCBL XML file or a XEDI
XML file, both with their  DTD's, and both using the same off the shelf
XML parser - the XML parser is still only going to do what you tell it to
do.

> Consequently, business applications need to do all of their 
> own validation.
> This was a necessary part of legacy EDI applications, and so 
> is not a huge
> problem for legacy systems. However, XML frees you from this 
> burden, saving
> huge costs in terms of writing application code (or buying a 
> commercial
> system to perform this validation).

Interesting. Legacy applications can be less dependant on special
validation, but is that 'business' validation (ex. this is a valid PO I just
got since the customer has good credit) or 'technical' validation (ex. I got
this qualifier code from a customer saying we have a new discharge port for
a
container). A new generation of applications ?

Can you maybe reword the explanation with some practical xCBL example to
show it's business strength.

Thanks very much
-Dave
 

------------------------------------------------------------------
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