Lists Home |
Date Index |
Joshua Allen wrote:
>People seem eager to forget how the world was before XML 1.0. Too-clever people can argue all day that "XML 1.0 is qualitatively not much better than CSV". But this misses the point. XML 1.0 has been able to achieve a degree of ubiquity and platform support that makes it "the obvious choice" for people who previously had to cho Why people are so hasty to go back to a world of multiple, incompatible encoding techniques is beyond me. For God's sake lets be happy that we have XML 1.0 and progress to the new millennium where we get to argue about incompatible schemas instead.
Having different encodings does necessarily mean incompatibility.
Good browsers support GIF, JPEG and PNG without any problem: if the
plurality, then having a few different mainstream alternatives with
different tradeoffs gives
richness. This is where, most notably, W3C XML Schemas fails: it does
not provide a mechanism to
allow parts of it that fail to be readily improved or swapped out.
People are stuck with
the whole thing.
A truism: XML is only the obvious choice because the underlying Web
infrastructure allows choices.
What I would like to see from Liam's conference would be a working
benchmarking suite, to allow
characterization and comparison of different (implementations of)
binary<->DOM and binary<->SAX systems. Plus discussion of whether the
current MIME headers
for content types and compression are satisfactory, and whether there
are several different requirements:--
one for "compressed XML", one for "random access infosets" and so on.
I don't see that working
towards standard binary infoset exchange formats necessary means that
there must only be one;
indeed, as I said, I think that is definitely the wrong expectation for
people to have in their heads.
The first step should be to ensure that plurality is supported, and
battle out what the characteristics and
uses of different formats are, *then*, to the extent that there is a
clear requirement and agreement,
develop or sanction a specific W3C approach. (What it means is that MS
should have its preferred
compression method but also support the one that becomes popular in
Linux; similarly, the Linux
people can have theirs, but also support the one from MS. For example
both of an ASN.1 encoding
and an optimized GZIP, etc. The most important thing is that the
infrastructure must support
multiple forms of binary, to allow market and technical forces to work
in favour of whatever the
current best choices are.)