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

["Welsh, David" <David.Welsh@nordstrom.com>]

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