[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Datatype section, or Binary Large OBjects in Business Documents
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:email@example.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"
Powered by eList eXpress LLC