RE: [xml-dev] Re: [ubl-dev] Top 10 uses of XML in 2007

["Michael Champion" <mc@xegesis.org>]

> -----Original Message-----
> From: Elliotte Harold [mailto:elharo@metalab.unc.edu]
> Sent: Monday, February 19, 2007 8:56 AM
> To: Stephen Green
> Cc: David RR Webber (XML); Stephen Green; ubl-dev@lists.oasis-open.org; xml-
> dev@lists.xml.org
> Subject: Re: [xml-dev] Re: [ubl-dev] Top 10 uses of XML in 2007
> 
> 
> Binary formats are not a
> magic panacea to improve performance. In many cases, XML is actually
> smaller than competing binary formats. (Compare OpenDocument to the
> equivalent Microsoft Office binary, for example.)

I think that is Steven Green's point - ZIPing the XML in ODF or OOXML documents creates a "binary" version not an XML text document.  Still, I agree with Elliotte that the net effect is to have the advantages of XML text because ZIP is so standardized and optimized for medium-to-large documents such as those one would create with OO or MS Office.  What's worthy of debate is whether creating an XML-specific optimized binary format ("binary XML" or "Efficient XML Interchange" (EXI) are the usual labels) has a net good or bad effect.

> 
> There are a lot of myths and wild guesses about performance. I don't
> doubt that people who never bother to crack open an analyzer or write a
> good benchmark will switch to binary XML for no good reason. That's a
> big reason I oppose it. 

I'm not sure I'm quite as cynical about the target audience, but the point is very well taken:  People should NOT follow the syllogism: "I have an XML performance problem, binary XML has better performance, so I should use binary XML to solve my problem." It is critical to understand where the bottleneck is, and address it in a way that preserves whichever of XML's advantages are critical to an application while mitigating whatever disadvantage is leading to the bottleneck.

> The only areas in which the arguments for binary
> XML are the least bit compelling are in the wireless space, and that has
> a lot more to do with battery life than document size.

OK, but there are other scenarios as well.  For example, it is usually true that XML messages (SOAP, POX, ebXML, whatever) are about 10x larger than comparable "binary" messages using the previous generation of technologies. *IF* that leads to bandwidth bottlenecks and the messages are not large enough to benefit from ZIP compression, a binary XML format might be useful irrespective of whether the network is wired or wireless. Likewise, one may find (as we do with SQL Server) that the XML parsing / serialization process is a bottleneck on the server, so users can configure things so that a binary XML format that is extremely fast to produce and consume BY THE SERVER is sent to the client layer to be translated back and forth to XML.  That's just a trick to move the XML processing burden to a less utilized processor, but it is a real use case for binary XML.

The interesting question is to what extent a W3C EXI standard will actually help outside the wireless domain.  I'm unpersuaded by what I've seen so far -- impressive compression seems to be achieved only if both ends of the wire know the schema.  It seems to me that if both ends (and all XML-aware intermediaries, e.g. WS-Security processors) know exactly what the format is, the app wouldn't need XML at all. Likewise, it doesn't help the "offload the expensive XML processing" use case because the EXI standard will not be a dump of anyone's proprietary data structures (which of course is good for interop even if it is bad for performance of the app that uses those proprietary data structures!).  But we shall see .. the W3C EXI WG has collected a mountain of information that I haven't tried very hard to make sense of. I think they are working on presenting it in a more digestible form, and then we can debate with solid numbers.