W3C home > Mailing lists > Public > www-tag@w3.org > December 2002

Re: binaryXML, marshalling, and and trust boundaries

From: Tim Bray <tbray@textuality.com>
Date: Mon, 02 Dec 2002 17:22:32 -0800
Message-ID: <3DEC0758.1020809@textuality.com>
To: Michael Mealling <michael@neonym.net>
Cc: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-tag@w3.org

Michael Mealling wrote:

> I for one would appreciate it. There are several protocols I've been
> working with that, due to their particular nature, would benefit from an
> efficient serialization that was very specifically _not_ 'just gzip'.
> The model we're working with requires the impact to the server to be
> very low as well since the cost to recover is higher than the cost to
> requery. If gzip is used then that relationship flipflops and the impact
> to the entire system is extremely significant. Thus the reason why we
> keep coming back to WBXML as the solution.

This is a tough problem.  If the tag density is very high relative to 
running text, you can try to binary-encode markup with a dictionary 
(what WBXML does IIRC); of course if you wanted to retain XML's virtue 
of being self-contained you'd want to include the dictionary in the 
message, which would blow off most of the benefit in the case the 
messages are short.  Another approach would be simply to be rigorously 
minimal in choosing tag names, e.g.

    <m a="33.34.44.55" from="foo@bar.org"><a u="3" h="ajfoeiw"/></m>

at which point the savings from compression are less significant.

If the markup density is lower, the problem reduces to that of 
compressing text, which is fortunately well-understood, the considerable 
redundancy in most XML compresses beautifully per all the standard 
algorithms, so you can pick any particular cost-effectiveness point from 
the menu.

I'd really want to see some hard statistical data about the 
characteristics of the message traffic in question before I went out on 
a limb as to the best way to deal with the problem.  Also it's not clear 
that there's a solution with acceptable cost-effectiveness across a 
broad spectrum of applications, even if the apps are limited to the 
wireless-networking space. -Tim
Received on Monday, 2 December 2002 20:22:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:14 GMT