This is Joe Gregorio's writings (archives), projects and status updates.

Binary XML


The Efficient XML Interchange Working Group has published the First Public Working Draft of Efficient XML Interchange (EXI) Format 1.0. EXI is a very compact representation for the eXtensible Markup Language (XML) Information Set that is intended to simultaneously optimize performance and the utilization of computational resources. Using a relatively simple algorithm and a small set of data types, it reliably produces efficient encodings of XML event streams.

You can call it anything you want, but that's Binary XML.

Update: Larry O'Brien points out that the situation is even worse than it appears, as they've designed in Pluggable CODECS.

After listening to Jon Udell's interview of John Schneider regarding efficient XML I understood for the first time why anyone would want such a thing: wireless communications. Of course, I still think that compression + XML is worth doing, but Mr. Schneider makes a good case. (Of course, I'm a total nobody when it comes to any sort of standards talk too, but that isn't stopping me from typing here :)

Schneider's argument came down to the power costs of antenna usage versus processor time (if I recall). This is a serve blow to the children of the future I think, as it makes initial hackability and discovery that much harder (but then again I knew people growing up who taught themselves Apple II machine language ...)

Posted by Josh on 2007-07-22


I have heard the "wireless" argument before and it doesn't hold water; if bandwidth was really the problem then an investment in compression algorithms or HTTP style Range: requests would help, and would do so for all formats, not just XML.

Personally I have trouble applying a technological fix to a social problem, where the technological problem is scarce bandwidth, and the social problem is an oligopoly that creates artificial scarcity to keep prices high.

Posted by joe on 2007-07-23

I found the description of the format so impenetrable that I just gave up reading it (since I don't plan to use it, it was not worth the effort...).

If what they want is a binary format for tables or arrays of strings, integers and binary lumps, then they don't really want XML's quirky infoset, they want arrays of tables or arrays of strings, integers and binary lumps. And in that case, what was wrong with XDR or ASN.1 -- or even some trivial binary encoding of JSON?

Posted by Damian Cugley on 2007-07-25

Impenetrable is a good description. I feel dumber from having even looked at the thing.

Posted by Jason R Briggs on 2007-07-26

Joe of course you make good points. Have you ever discoursed with Mr. Schneider on these topics? From the Jon Udell interview there were apparently some studies done that demonstrate the usefulness of the Efficient XML side of things, but I have no idea whether or not there were any such tests for gzipped HTTP or ranges or whatnot.

I'm disappointed that yet another standard for wireless communication has come about. If WML never took off why another standard is supposed to fix things is beyond me.

Posted by Josh on 2007-07-26

It is always good to take a step back and look at technology and question if the technology is attempting to act as a band-aid for a larger problem. You are a master at it. However, it should be pointed out that from a technical perspective Binary XML is targeting more than just bandwidth optimizations. It also improves CPU utilization. A big concern for many customers. The thing about XML is that it is extremely expensive to parse and transform. Adding gzip/zip or other generic compression technologies to an XML stream reduces bandwidth usage with a price of increasing the CPU cost because the producing side must compress the file prior to sending it and the receiving side must uncompress the file parsing and transforming it. Binary XML optimizes both CPU and bandwidth usage by both sending a smaller file over the wire and forgoing the (de)compression costs associated with gzip/zip. The decompression step can be eliminated because the receiving side knows the format and can deal with the binary format directly( assuming both sides know Binary XML). Likewise the sending side never needs to produce a text version of the XML file, it just need to create the binary representation thus no compression is required.

Posted by Tom on 2007-07-28