Subject: Re: Throwing the baby out with the bath water
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: <email@example.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"
Powered by eList eXpress LLC