Re: binaryXML, marshalling, and and trust boundaries

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