[FoRK] binary XML
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
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
> 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
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
More information about the FoRK