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