[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
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.
Powered by eList eXpress LLC