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

[Tony Weida <TonyW@EDIFECS.COM>]

John,

In fairness to those you criticize for not sharing your knowledge and
appreciation of the "direct" XEDI approach, where is it documented?  I've
looked at the XEDI white paper:

	http://www.xedi.org/pdf/XEDI_Tech_Paper.pdf

As of today, it doesn't mention the direct approach in XEDI.  On the
contrary, it says "XMLSolutions [acquired by Vitria, your employer] uses
only a handful of element names such as transactionSet, segment, element,
value and name. All other information is conveyed as the attributes or
contents of these elements."  Indeed, it goes on to argue at length against
(what seems to be) the direct approach, so I can well understand why Arofan
and others evaluated XEDI as they did.

Tony

> -----Original Message-----
> From: John Evdemon [mailto:jevdemon@vitria.com]
> Sent: Thursday, July 19, 2001 1:59 PM
> 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.
> 
> 
> ------------------------------------------------------------------
> 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
>