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

[John Evdemon <jevdemon@vitria.com>]

On Tuesday, July 17, 2001 1:30 PM Arofan Gregory, wrote:
> 
> I do not feel like arguing the merits of existing standards - and I am
both
> EDIFACT's biggest fan and worst critic, depending on what aspect of EDI
> you
> are talking about (good: it provides a huge wealth of valuable experience;
> and bad: it has experienced a kind of bloat over the years that wasn't a
> problem with point-to-point TP relationships but that is harshly inimical
to
> interoperability when you're trying to leverage the network effect of a
> global network such as the internet).
> 
I'm not sure how EDI can be considered harmful to interoperability since it
was never intended to leverage the "network effect".  EDI is designed for
point to point transactions (such as those in the direct materials market) -
this is why many exchanges have found it to be quite challenging to
implement EDI support (most exchanges are designed to support an indirect
materials market (e.g. MRO)).   

The "network effect" implies a shared level of semantics - EDI provides the
basic semantics that have been utilized to enable several decades of
interoperability.  Interoperability would be quite difficult if EDI did not
provide a basis upon which businesses could define their transactions.  
 
> Where it [XEDI]
> 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. 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.
>
Your point is a bit muddled, I think.  Validating business semantics depends
on the robustness of the information model.  The same argument can be made
about xCBL or any other markup initiative - the usefulness of the validation
process is directly related to the quality of the information model.  

You stated earlier that you were familiar with XEDI but it appears that you
are not.  We support an "indirect" approach in which (as you appear to
state) one DTD/Schema can represent any instance of an EDI transaction
(since the DTD/Schema only represents the structure of the EDI transaction,
not the actual instance).  This approach offers the benefit of using a
single DTD/Schema for validation of any instance - however the usefulness of
the validation suffers (since the DTD/Schema only models the structure of an
EDI document, not the semantics of a particular instance).

XEDI also supports a "direct" approach in which we provide DTDs/Schema for
specific instances of an EDI transaction (e.g. Purchase Order, Invoice,
Mortgage Note, etc).  The DTDs/Schema preserve the semantic rules associated
with any EDI transaction (any version - EDIFACT or X12).  The "direct"
approach enables the validation of both the semantics and the structure of
any EDI transaction. The DTDs/Schema do not simply validate structure since
that would be worthless - the document would always be valid, regardless of
the semantics utilized.  

Users of XEDI can determine which approach works best for them (although the
majority of users elect to use the "direct" approach described above). 
 
> 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).
> 
XML does not free you from the burden of performing business validation
(although it may lighten the load, given a well-designed information model).

Applications usually need to perform additional validations because
different companies will have different business rules to enforce.  EDI
recognized this need many decades ago and enabled companies to develop and
share their implementation guidelines (IGs).  Regardless of the
recommendations of the UBL WG, businesses will still enhance/extend/modify
it to suit their own needs (much like corporate IGs).

> When we talk about enabling SMEs, one of the biggest challenges is
> lowering
> costs, and XEDI fails to embrace a basic aspect of XML processing that
> makes
> this possible. It is  a useful technology, but it is not a good basis for
a
> language that is focused on describing business semantics, rather than
> structural ones.

Can you clarify how XML lowers costs, but XEDI (also XML by the way) does
not?  What basic aspect are you referencing?  I don't understand your point.

XEDI appears to be our best option for describing business semantics since:

1)  Its available and in production today 

2)  It uses the global standard (X12 and EDIFACT) e-business structures and
semantics that businesses have been using for decades.  

3) It supports any X12 or EDIFACT transaction, from any version of the
existing standards:  
 - It can be used for simple structure validation of any transaction
 - It can be used for both structure and semantic validation of any
transaction
 - It uses current e-business metadata standards, enabling non-EDI shops to
leverage a rich set of metadata for transaction definition/validation

4) For EDI shops, the transformation process supports all of the additional
transaction protocols (e.g. generation of receipts, turnarounds, etc.)
recommended by X12 and EDIFACT.  This not possible using a DTD or Schema
since it involves process - not just syntax and semantics.

5) It enables large corporations to preserve their EDI
infrastructures/investments by extending EDI support to SMEs.  EDI
transactions are transformed into XML which can be transmitted to SMEs as
raw XML (for possible SME-side consumption) or transformed into HTML (or
other formats) - enabling the SME to consume EDI messages in their format of
choice.  Since XEDI also transforms XML into EDI, the SME can electronically
communicate with large EDI-enabled corporations in a user-friendly fashion
(no more faxes, email attachments or hard copy).