RE: Datatype section, or Binary Large OBjects in Business Documents

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

Brian Hayes said  "if the document (presumably via an 'Attachment' core
component) just references the attached file, additional validation is
required beyond what a typical schema based parser would provide."  See
http://lists.ebxml.org/archives/ebxml-core/200101/msg00052.html.

Brian:

The TR&P Message Service Specification 0.91 reminds us that "an ebXML
Payload Container may be a completely encapsulated ebXML Message."  In
that case, if the attachment is another (recursive) ebXML message, then
I would suppose ebXML "software" would allow you to invoke ebXML all
over again for that embedded message!

More likely, though, is the attachment would be processed by the
appropriate program based on the MIME content header (e.g, a
Content-type: application/msword would ultimately be handled by
Microsoft Word).

In general, I think most attachments would be set aside and safely
stored away;  rarely would they be processed immediately in the
translation or transformation stage since they would usually be
human-readable documents.  Ultimately, when a human sees the end-result
of an ebXML message, say when looking up a mortgage insurance
application form, the GUI would have a link to the persisted attachment
which in this case might be a JPEG image of the real property.  The only
thing that would be checked at translation time would be the fact that
some JPEG attachment indeed existed (if in this ebXML message).  Since
we also have to make provision for referring to attachments in other
messages, even the absence of the attachment in *this* message would not
necessarily be an error.

At other times, it *will* be necessary to mechanically process the
attachment along with the ebXML business message.  An example from X12
EDI will suffice:  the HIPAA (Health Care) ASC X12N 275 (Additional
Information to Support a Health Care Claim or Encounter) transaction set
implementation convention (MIG to our European friends) contains
embedded within it an HL7 (Health Industry Level 7) message. The two
standards, X12 and HL7, serve to convey business and clinical
information, respectively.  Rather than devise new segments to hold
clinical observations in X12 for supporting the medical claim, it's just
simpler to embed an HL7 message as "binary" data within the 275.  In
this case, some sort of  EDI translator will have to be recursively
invoked to read the embedded HL7 message in order to extract the claims
attachments.  If the HL7 message has (syntax) errors in it, that
information needs to be percolated back to the 275 processing so an
application error acknowledgment can be generated.

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

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"