W3C Efficient XML Interchange format draft published
The proposed format is:
"The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of data types, it reliably produces efficient encodings of XML event streams"Or in plain English - a compression algorithm for XML. As expected criticism was soon to follow. The first was Elliotte Harold who simply said that
The Efficient XML Interchange Format is neither efficient nor XML nor interchangeableJoe Gregorio said that they can call it what they want but it is still Binary XML and on the XML-dev mailing list Michael Champion asked "is it time for the binary XML permathread to start up again?". On the thread that ensued few people raised the issue of the difference between EXI an previous attempts for a binary interchange formats like the Fast Infoset format (FI)
Santiago Pericas-Geerstsen (who is an editor in the W3C XML Binary characterization working group) responded to the last claim and said that EXI is better than FI since it "knows" it deals with XML and not some general infoset. This pre-knowlege allows EXI to produce more compact results. Also EXI works in whole bytes rather than FI that works at the bit level which makes EXI less CPU intensive. Santiago also says that internal tests of EXI performance showed promising results.
In any event, it is also interesting to note that the Technical Architecture Group (TAG) was weary of the need for a binary XML format in a report they issued back in May 2005:
We therefore believe that the benefits of a binary XML must beWill binary XML catch-on this time around? Only time will tell.
predictable and compelling in order to justify development of a
if XML 1.x is inherently capable of meeting the needs of users, then our
efforts should go into tuning our XML implementations, not designing new
formats. Benchmark environments should be as representative as possible
of fully optimized implementations, not just of the XML parser, but of
the surrounding application or middleware stack.
Why not ASN.1 ?
Elliot's problem and why he is wrong
In this case EXI is gaining efficiency by treating certain datatypes more efficiently than pure character strings. Is that justified? Well in many cases yes it will be.
The real point tho, is that EXI is just *one* potential infoset serialization, and there just isn't going to be "one size fits all".