Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Microsoft FUD on binary XML...
Bob Wyman wrote:
>Jeff Lowery wrote:
>
>
>>What can be achieved by binary XML that can't
>>be similarly achieved using well-known text
>>compression algorithms?
>>
>>
>...
>
>But, be careful when considering examples like the one above. It is
>very easy to provide examples where binary formats compress amazingly
>well. In real life, a binary format *will not always* compress data
>well enough to be worth the trouble and you can't really make the
>claim that a binary format will be faster to encode and decode. In
>general cases, you should probably prefer the text encoding and only
>move to binary if you *know* that it will be useful for your specific
>datasets and processing requirements.
>
I don't know why you say "you can't really make the claim that a binary
format will be faster to encode and decode". Certainly some binary
formats are going to be faster to encode and decode than the equivalent
text representations for any reasonable documents. Just using an
efficient handle-based approach to element and attribute names will give
you this, while also reducing the document sizes.
As for the larger issue, I see three different clusters of interest in
using non-text representations of XML Infosets:
1. Reducing transport size for general documents - this is handled
very well by gzip and friends, though at the cost of added
processing overhead and latency issues
2. Reducing processing overhead for general documents - this is
something that my XBIS format (http://www.xbis.org) addresses in
particular, along with similar schemes; XBIS also gives some
reduction in document size (which can be substantial, especially
for something like SOAP and especially when messages are streamed
over a single logical connection), but the focus is on speed
rather than size
3. Schema-enhanced Infoset transfer - typed data exchange, where the
types are known in advance and the XML representation is in many
ways incidental; this is where I'd think ASN.1 really hits a sweet
spot. Because this is based on typed (i.e., binary) data it
potentially allows better solutions for a particular application
than general solutions of types (1) and (2).
I think these are all important concerns. I do find it a little baffling
that so many people recognize (1) as a valid concern and willing endorse
using gzip transformations of XML documents to address it, while
refusing to recognize (2) and (3) as valid concerns or accept other
types of transformations of XML documents.
- Dennis
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
