- From: Michael Mealling <michael@neonym.net>
- Date: 05 Dec 2002 11:46:27 -0500
- To: Tim Bray <tbray@textuality.com>
- Cc: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-tag@w3.org
On Mon, 2002-12-02 at 22:26, Tim Bray wrote: > Michael Mealling wrote: > > > So imagine what you would want to do to XML if DNS version 2.0 had to > > use it but still had to maintain its current 'network footprint' and > > client/server interaction methods. > > > > Also, to be clear, this isn't for the wireless world, its for the > > current internet but at a scale that HTTP over TCP simply can't touch. > > So you are hypothesizing that there is a method for compressing > arbitrary XML that will do a good job on this particular application and > also span a broad-enough range of usefulness that it's cost-effective > for W3C or IETF or someone to invest in standardizing it? Yes. With the exception that 'abitrary XML' may not be as hard a requirement as some of the others. > BTW, does WBXML as it stands meet your needs? As far as I can tell, yes. The reason I'm asking this question is that there is a large amount of FUD out there about WBXML that I can't seem to get any real answers for. Is that FUD justified? Is there some incompatibility problem with it that I'm not aware of? If the FUD is just limited to the "binary XML is a bad idea" realm then that I can successfully deal with. I've just heard no definitive documentation about the applicability of WBXML. Maybe an applicability statement from the TAG about when something like WBXML is appropriate and what the drawbacks were would be more appropriate than a simple 'pshaw'. > Another approach would be to define a custom binary format for the needs > of your application and provide a canonical mapping to a well-defined > format for purposes of interchange outside the application. Because > it's not obvious that XML is well-suited to the needs of the application > you describe. -Tim That was the original idea. The format I did extensive work with was something called BLOB [1] but what drove me to wanting something in XML was several features/requirements: 1) in each case the payloads exchanged between the client and server are also in XML. Having a non-XML format contain arbitrary XML was much more inneficient than encoding everything as XML and serializing that out as one binary chunk. 2) The number of situations where XML features such as character sets, container relationships, well formedness vs validation type issues (be liberal in what you accept bla bla...), etc turned up caused me to have to re-create many solutions in the new binary format that XML had already solved for me. 3) Since both the client and server were already dealing with XML in either its datastore or client cache, it was a _huge_ processor and developer time sink to parse a binary format just to turn around and stick it back into a DOM tree for internal processing. So, the point of all that is that, since the TAG is taking up this issue, I think one of its deliverables should be some guidance on the various XML compression methods and their applicability. GZIP will probably do for most methods but some additional statements about why/when something like WBXML is architecturally useful/safe would also be nice. -MM [1] http://www.ietf.org/internet-drafts/draft-moore-rescap-blob-02.txt
Received on Thursday, 5 December 2002 11:49:25 UTC