[
Lists Home |
Date Index |
Thread Index
]
On Apr 7, 2005 12:37 PM, Elliotte Rusty Harold <elharo@metalab.unc.edu> wrote:
> Far too much effort has been spent shouting supposed self-evident truths
> about how much faster/smaller/sexier binary formats are. Little in the
> way of evidence has been produced,
As someone who has been (personally) receptive to the idea of "binary
XML" technology and possibly even a single standard IF it could cover
a wide range of cases , I must say that this was my biggest
disappointment when reading the XBC final document. They developed
decent use cases, attributes to measure, and measurement
methodologies, and collected a number of prototype formats and
implementations, but didn't put them all together and generate some
numbers. Rather than those Yes/No entries in the table for how the
formats met the criteria, someone could actually run tests and plug in
real numbers. I can only assume that those who know what the numbers
would be also know that they do not support the case that a single
"binary XML" format can be both small enough and fast enough (not to
mention the 15 other attributes!) to make much of a difference.
Otherwise, why not publicize them and address the concerns that the
TAG expressed?
I fervently hope that the W3C doesn't move forward with a followon WG
until that quantitative evidence is available to all concerned. Until
then, we're back where we started - we know that some formats are
dramatically faster OR smaller than XML for some set of use cases, but
we don't have any reason to believe that one format can do it all
across use cases, or even that one could hit a reasonable 80/20 point
compared with XML. The idea of forming a WG to do some computer
science here, trusting that an acceptable size/speed tradeoff is
possible while maintaining XML API/tools/datamodel/etc. compatibility,
is at best implausible at this point.
> Personally, I'm not convinced that there isn't another factor of ten
> performance gain to be had in the world of real XML parsing, though
> doing that will probably require ditching DOM and SAX in favor of a more
> performance tuned API. Still, I doubt we've yet hit the end of the line
> when it comes to XML parsing algorithms. I could well be wrong about
> that, but it would be truly ironic if two weeks after binary XML goes to
> REC, some grad student somewhere releases a text parser that beats the
> pants off the binary parsers.
Noah Mendelsohn made that point in a very compelling way at the W3C
binary workshop in September 2003. He reiterated it on the TAG list
the other day, noting that the mainstream Java XML tools were designed
for conformance, not performance, and serious brainpower is only now
beginning to be thrown at the problem of efficiently parsing XML and
conveniently consuming the result.
>
> I suspect this would be more likely to happen if companies like Sun
> devoted their brain power to XML parsing algorithms rather than
> inventing new formats.
I think it's important to focus on people/problems/projects and not
who they work for. MS as a whole is extremely skeptical about "Binary
XML" standardization, but nobody has decreed that Binary XML is Evil
and is off the radar as a solution. Sun as a whole seems receptive to
standardization, but I doubt if anyone there has decreed that Binary
XML is the One True Path and parser optimization is pointless. Almost
everyone I talk to on both sides of the philosophical divide (or the
.NET / Java divide) has an appreciation of the dilemmas, and I'll bet
there are material Day Job rewards waiting for clever solutions to
actual customer problems, whether they involve new formats, new
algorithms/APIs, finding an efficient subset of XML that hits the
99/01 point for their use cases, whetever. The most important thing
IMHO is to not prematurely standardize on something we will all regret
in a few years, but not to prematurely reject options based on
preconceptions of one sort or another either.
I do think that the burden of proof is on those who would break things
that actually work without compelling evidence that would make us much
better off down the road. To be fair to the XBC people, until we
really and truly see XML 1.0 working for the use cases that they laid
out, I'm planning to keep an open mind about how to make the XML
family of technologies work better for all the users and potential
users. For now, various "binary XML" technologies definitely have
their place in specialized domains and scenarios, but nobody has come
anywhere near demonstrating that a "binary XML" standard would do more
good than harm. For that matter, I don't see how it is plausible to
believe that a consensus can be reached on a format that trades off
the needs of the wireless people for cheap compression and the needs
of the enterprise messaging people for processing speed.
|
