[FoRK] binary XML

Eugen Leitl eugen at leitl.org
Wed Jan 19 06:34:05 PST 2005

On Wed, Jan 19, 2005 at 08:54:48AM -0500, Mark Day wrote:
> I'm not sure I understand who is really supposed to benefit from a binary
> XML standard.  The discussion appears to be taking place in a zone where
> people are just looking at XML and not the larger context of how it's
> used/moved.

I could imagine that people who balk at the overhead of copying a buffer
from an incoming packet would like a binary format that doesn't require 
added latency due to compression (if you're worried about microseconds, 
mentioning gzip appears ludicrious), and saves memory bandwidth by being a 
tight representation.
> If the goal is to reduce bits used in storing XML at a particular device,
> that can be accomplished by either having the device do the compression
> itself or by using a distilling proxy (Fox & Brewer,

Compression hardware is not free, both in terms of gates and latency added.
I certainly can't add it to some existing, heterogenous hardware, especially
if I'm used to free software coming via network.

> http://citeseer.ist.psu.edu/fox96reducing.html).  No need for anyone else to
> know/care about the compressed representation.  Since it's unlikely that

The CPU cares. 

> people can design a single format that maximizes both space-efficiency and
> time-effiency (of parsing & processing), whatever standard was decided, some
> people might still need to do their own local representation. 

Now this is the interesting part. Can you make it binary, standard, open and
> If the goal is to reduce bits on the network, paired
> application-accelerating appliances like a Riverbed Steelhead setup
> (www.riverbed.com) are going to do a better job than a special file format,
> especially because they'll be able to do the optimization across multiple
> messages and more traffic types than just XML. [Full disclosure: I work at
> Riverbed.]

Nice, but I can't ftp hardware (even if it was free hardware).
> If the goal is to reduce bits on the network while using current web
> browsers (i.e. a "single-ended" solution), application/gzip is already

If I'm throwing XML over LAN, I can readily see the advantage of using a
binary format on slow (100 MBit Ethernet, 400 MHz SPARC) machines with tight
(less than a GByte), expensive ($$$) memory. Using gzip will actually
exacerbate the problem in this case.

> there.  I'm not sure whether the wrapping of a text/xml in there works out,
> but getting that right still doesn't require a "binary XML" as much as it
> requires tweaking some MIME-related specs.

Eugen* Leitl <a href="http://leitl.org">leitl</a>
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net

More information about the FoRK mailing list