RE: Datatype section, or Binary Large OBjects in Business Documen ts

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

An interesting question to ask would be:
  Is the document valid if an attached file (BLOB) is missing from the
message?
  Not that I would recommend it, but, if the BLOB is specified by the schema
as being in the document (first suggestion in my technical tip on "How to
Support BLOB Objects in SOX Schemas":
http://www.xcbl.org/newsletter/apr2000.html#16), then schema based parsers
can validate the existance of the BLOB just like any other element.
However, 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.  For example, if we have a
URI type that is used to reference a file (as in SOX), what piece of
software is responsible for making sure that the referenced file actually
exists?  If it doesn't exist, in what cases would the document not be
considered valid? Would the receiving trading partner prefer to accept the
document and then use some out-of-band way of getting the referenced file?
What happens in EDI environements today?

/Brian Hayes

> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Tuesday, January 09, 2001 8:22 AM
> To: Bob Haugen
> Cc: ebXML Core
> Subject: RE: Datatype section, or Binary Large OBjects in Business
> Documents
> 
> 
> Message text written by Bob Haugen
> >
> 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.
> 
> <<<<<<<<<<<<<<<
> 
> Notice that XML V1.0 has unparsed entities for this - and uses URI
> to point to them (and usually a ENTITY defination &binary_goup; )
> referencing mechanism.  And this is why you have NOTATION to
> be able to associate an external processing component to 
> handle that binary (most typically a GIF or JPG for example).
> 
> Now of course we have XML V1.85 - (soon to be XML V2.0 ?!) we
> have to allow people to be more clever than is good for themselves...
> 
> DICOM 3 is the measure I use here.  Letting engineers design
> business solutions results in DICOM 3 type implementations.
> DICOM 3 would certainly love being able to embedded the
> binary into the XML itself, and more, links from the XML into
> the binary, chained binary fragments, et al!
> 
> Best practices for ebXML should certainly keep to the simple.
> 
> Ho hum.
> 
> DW.
>