[
Lists Home |
Date Index |
Thread Index
]
On 8/26/05, Bullard, Claude L (Len) <len.bullard@intergraph.com> wrote:
> Microsoft has to take the credit and
> the blame for what is about to happen. Speeding up XML
> and compressing the payloads is a big deal. Those who
> don't think XML Binary is going to happen are putting
> rocks in a river that will simply flow around them.
Just in case this was partially directed to me (I've been pushing the
MS party line on the W3C lists on this topic), let me make one thing
perfectly clear :-) There's no doubt that speeding up XML and
compressing payloads is a big deal in some important scenarios.
Binary XML is happening, here, at all the big vendors AFAIK, at W3C,
and in a bunch of small innovators.
There are three big questions that we don't think have good answers so
far, but should be answered before a binary XML format is
standardized:
- Is this technology ready for widepread standardization? I lean
toward "no", because a) there is a tradeoff between speeding up XML
and compressing the payload, and different use cases would adjust this
tradeoff differently and b) we are as an industry learning an awful
lot about how to do this better, so freezing the technology at the
current state is short-sighted.
- Can a single "efficient XML interchange" (aka EXI, "binary XML" is
no longer au courant) Recommendation hit a good 80/20 point across
the major use cases? I'm keeping an open mind on that, but I fear
that many major stakeholders want a different 20%.
- Can EXI be standardized without undermining XML's basic value
proposition of universal interoperability? That's probably the most
controversial. Obviously a lot of people who post here have been
shouting "NO!". The EXI advocates seem to be saying "sure, no problem,
but let's not worry about that little detail now, trust us to get it
right in the spec". I tend to think that this could be done in
principle and over time, but I'm not sure it can be done in a way that
works with XML 1.0. Overloading the encoding declaration might be
possible, but some EXI advocates shudder at the "huge" 32-character
overhead and XML text advocates point out that this would make it
harder to distingish the character-level encoding from the
infoset-level encoding, e.g. an EXI-encoded document in UTF-8 from an
EXI-encoded document in ISO 8859. So, I don't know how an EXI
Recommendation in the next couple of years could avoid disrupting XML
interoperability for the existing installed base, although I
appreciate the argument that it would extend XML's reach to new
environments that can't use XML until it is more efficient.
|
