Re: Throwing the baby out with the bath water

[David Lyon <djlyon@one.net.au>]

William,

It's certainly true that mime documents can carry Edifact documents as body
parts as you have described.

From a message perspective, there is little difference between embedding an
Edifact/X12 document in an ebXML document or as a body part. It's just
semantics, and a different encoding technique.

When embedded as a body part, it sits in the message (from memory) a bit
like this:

 -----Mime Type Business/Edifact 2058 bytes -----
 UNH|....
 UNA|...
...
 ----- -----

And if it's in the ebXML body its:

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

I would argue that it's easier to manage a single Message Body without
attachments than messages with attachments.

The reason is that Edifact/X12 documents are usually so small (1k-4k) that
they can quite easily fit in as extra message body text.

Edifact/X12 is, has been and will continue to be important to e-commerce.
Imho they should be considered integral to any ebXML message. To relegate
them to being an attachment (forgive my sentimentality) like a .jpeg is a
little harsh. My vote would be to keep them in the message body for however
long people feel they need them.

Also, although not as important, is that from an integration perspective,
processing seperate attachments in a programming language like VB or
whatever is an extra step and with any extra step there's the possibility
for errors.

In production environments, attachments get 'lost or seperated' from the
original messages from time to time, and it uses a lot of human resources to
get things reconciled again.

Of course, there are going to be those who don't mind extra complexity and
don't see attachments as being a complication. I accept that as an argument,
but whichever way wins out, a standard way for including Edifact/X12
documents really should be part of the ebXML specification somewhere.

Regards

David Lyon

----- Original Message -----
From: William J. Kammerer <wkammerer@foresightcorp.com>
To: ebXML Core <ebxml-core@lists.ebxml.org>
Cc: ebXML Transport (E-mail) <ebxml-transport@lists.ebxml.org>
Sent: Wednesday, April 25, 2001 1:52 AM
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: <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"
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
>