OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC