Re: Throwing the baby out with the bath water

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Philip Goatly reminded us that "to completely abandon everthing that
EDIFACT etc has done would be 'throwing the baby out with the bath
water.'"

I think Phil may have been suggesting that EDIFACT be used to inspire
the modeling of core components, though others have been more explicit,
such as Jean-Luc Champion and Bob Miller.  But David Lyon might be
interpreting this merely as "coexistence" - whereby an ebXML document
can have "...a tagged section to hold legacy edifact or X.12 documents."
His example shows "a tag <Edifact></Edifact> or <X12></X12> that holds a
version of the document in EDI format." -

                      <Edifact>UNA|........ UNB|..... </Edifact>

There's no need to nest a "legacy" EDI message within another XML
document - ebXML provides a first-class means of transporting EDI
payloads. The TR&P Message Service Specification 0.99 (20 April 2001)
includes in Section 4: Introduction:

   ...the specification defines a flexible enveloping
   technique that permits ebXML-compliant messages to
   contain payloads of any format type. This versatility
   ensures that legacy electronic business systems
   employing traditional syntaxes (i.e.;  UN/EDIFACT, ASC
   X12, or HL7) can leverage the advantages of the ebXML
   infrastructure along with users of emerging technologies.

Though there are no explicit examples of this technique, I'm going to
guess it's compatible with EDIINT; see the IETF's Electronic Data
Interchange-Internet Integration page at
http://www.ietf.org/html.charters/ediint-charter.html.   For example, a
"legacy" X12 interchange would be MIME encapsulated with headers like:

   Message-Id: <ebac3753.19d6.04bcaec1b@cyclonesoftware.com>
   Content-Type: application/EDI-X12
   Content-Transfer-Encoding: base64

Base64 Encoding would be used to ensure that non-printable EDI
delimiters don't gum up the MIME works.  See the IETF RFC 1767, MIME
Encapsulation of EDI Objects, at http://www.ietf.org/rfc/rfc1767.txt,
for a description of the applicable Content-Types for EDI.

TR&P's elegant and powerful SOAP-based Messaging Services has the
glowing prospect of becoming the "Grand Unified" transport framework I
predicted it would become back in June 2000 - see "Re: ebXML will end up
being too expensive for small business," at
http://lists.ebxml.org/archives/ebxml/200006/msg00032.html, and even
earlier, in April 2000, in response to Ian Galbraith in "Re: Summary of
XML Datatypes as required for B2B applications," at
http://lists.ebxml.org/archives/ebxml-core/200004/msg00032.html.   My
comment just yesterday is simply a repeat of my previous predictions
that the ebXML Messaging Services "...is giving folks something much
better than what they have now, replacing EDIINT AS1 and AS2 for
point-to-point EDI over the Internet."

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"