[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold wrote:
> At 10:45 PM -0800 2/26/03, Don Box wrote:
> Yet another approach would be to define an alternate serialization
> of the Infoset (much as WBXML [WBXML] has done) that serializes
> xs:base64Binary and xs:hexBinary typed data as the actual octets,
> rather than text-encoded octets. One can easily imagine
> on-disk/on-wire representations that allow opaque data to coexist as
> raw octets with the encoded characters of the surrounding XML
> structured data.
>
> If I'm reading this right (and I'm not yet sure I am) then the authors
> propose a new serialization of the Infoset which allows embedded binary
> data to be directly or indirectly included in XML documents. This is the
> most incompatible subset I've seen yet, in that it allows what are now
> malformed documents.
I don't think that that is what the authors mean (though I don't want to put
words into their mouths). Given the XML document <canned>DEADBEEF</canned> you
could produce a binary infoset ("alternate serialization of the Infoset") that
would store DEADBEEF not as a hex or b64 string but directly as binary data.
BinXML does this and quite naturally one does gain space (and time as you can
retrieve the binary data directly through low level APIs). Given a binary
infoset format that supports this it doesn't lead to malformed documents, and if
you were to serialize it as XML you would get <canned>DEADBEEF</canned> back,
which is a perfectly well-formed document.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
