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

[Bob Haugen <linkage@interaccess.com>]

The Business Process group has defined UnstructuredDocument
that I think does some of what William Kammerer advocates below
(separating BLOBs from StructuredDocuments..)

-Bob Haugen

-----Original Message-----
From:	William J. Kammerer [SMTP:wkammerer@foresightcorp.com]
Sent:	Monday, January 08, 2001 7:46 PM
To:	ebXML Core
Cc:	ebXML Transport (E-mail)
Subject:	Re: Datatype section, or Binary Large OBjects in Business Documents

In "More on Finance Sub-group comments - the Image/Picture Aggregate," I
discussed separating file objects from the ebXML business core
component, using a reference to a MIME payload object instead. See
http://lists.ebxml.org/archives/ebxml-core/200101/msg00040.html.   This
might be preferred by TR&P, and is considerably more elegant than the
equivalent we've endured in X12 EDI using the BIN and BDS segments.  It
also avoids having to define Content Type enumerations or values (e.g.,
am I a JPEG, a PDF or a Word Document?) that had to be carried along in
the EFI (Electronic Format Identification) segment to describe the
binary object in the following BIN or BDS, since MIME makes allowance
for all of this stuff in its headers.

UN/EDIFACT avoided all along carrying BLOBs (Binary Large Objects) in
messages - instead providing special control segments and constructs in
ISO 9735 (EDIFACT syntax) V4 keeping the binary data separate from the
message which referred to it.  X12 followed suit, belatedly, with the
102 - Associated Data - transaction set.

Separating binary file objects from the core component and the business
document also avoids the parser having to pass over possibly tons of
encoded binary data just to get to the end of the binary element,
allowing validation to proceed more quickly.  Since nothing will often
need be done with the binary image or file until the message is
validated, it's easier to set it "aside," or ignore it altogether, if it
is maintained as a separate object in the payload.

Therefore, can we discourage the use of the Schema "binary" datatype (or
more properly, datatypes that are derived from binary) in the Datatyping
document? See Betty Harvey's e-mail at
http://lists.ebxml.org/archives/ebxml-core/200101/msg00030.html.  Is
there any conceivable reason to still support the "binary" datatype?

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"