[
Lists Home |
Date Index |
Thread Index
]
At 2:43 PM +0100 2/27/03, Robin Berjon wrote:
>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.
Perhaps. It seems you're arguing (and please correct me if I'm wrong)
for a binxml that has more information than a plain vanilla XML
document. Your vision of binxml includes type information. That is,
it knows what's a string and what's an int and what's a date and
what's binary data and so forth. Is that accurate?
If so, it seems that your BinXML is really not BinXML at all. Rather
it's a BinPSVI or something like that. There's more information in a
BinXML document than there is in the equivalent XML document. You
have tag names, content, attributes, and types. XML only has tag
names, content, attributes. No types.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
|
