[
Lists Home |
Date Index |
Thread Index
]
On Sat, 05 Feb 2005 07:25:36 -0500, Elliotte Harold
<elharo@metalab.unc.edu> wrote:
> Screw the old-timers. We're a trivially small part of the XML universe,
> just like the trivial number of people who actually write XML parsers.
> But do remember the huge number of people who actively and productively
> use XML on a daily basis, whether they know it or not, and who will be
> massively inconvenienced by the mere existence of a new version when the
> old one serves their needs just fine. The XML 1.1 debacle made it clear
> that the W3C has no institutional recognition for the value of stability
> for stability's sake. They are categorically unable to see that a flawed
> but stable spec can be preferable to a constantly improving spec. Make
> no mistake: XML 1.0/1.1 is flawed. However, the flaws are small and
> easily ignored or worked around. There is no problem with XML 1.0 that's
> big enough to justify any backwards or forwards incompatible revision.
That is definitely the issue here -- is the world getting so much
benefit from XML 1.0 that trying to improve it would make things
worse, or are the crufty parts, inconsistencies, inefficiencies, etc.
causing real pain and will shorten XML's lifetime? It's a hard
question. If anything, Microsoft as a company leans toward keeping
XML things stable in the name of maximizing interop (which was why I
linked to the Gates piece), even though one might plausibly argue that
it would get more tool revenue My personal guess is that a review,
refactoring, and very gradual redeployment process would meet both the
needs for evolution and the needs for stability and predictability.
The assertion that the problems with XML 1.0 are small, easily
ignored, and not worth fixing is plausible but also highly disputed.
I supect that we will ultimately perform a large scale social
experiment: W3C won't try (or fails because of the non-technical
"political" challenges) to define a really workable profile of (XML +
namespaces + xml:base + XInclude + xml:id) - a lot of cruft, but
various de facto profiles of this get defined. The things that will
define the profiles include SOAP (which tossed DTDs and PIs), APIs and
various object binding tools (their users don't want to have to know
DTD cruft, the XML whitespace rules, etc.), binary XML (outside W3C
politics I can't imagine a serious use case for DTD stuff in the
wireless world), and authoring tools (which will prosper in the market
to the extent that they hide all but the barest bones of XML, I
predict). At some point down the road we'll see whether the various de
facto profiles fail (leaving XML 1.0 as the undisputed interop
standard), converge into somethat that can become XML 2.0 in 10 years
or so (much as SGML best practice converged on XML 1.0), or whether
they diverge into separate descendants of XML for specific communities
and the XML interop dream fades away.
The hard question is where the "window of standardization"
http://web.archive.org/web/20031204174002/http://java.sun.com/people/jag/StandardsPhases/index.html
is for XML simplification. Too early, we don't know enough about what
the real pains are and where the sweet spot lies in the technologies;
too late and this gets bogged down in real money and corporate power
politics and nothing will happen until a new generation tosses it all
and reinvents the whole thing. Since they will probably make the
opposite mistakes that XML did (or maybe as Rick said, makes the
people unhappy with XML happy and the people happy with XML unhappy),
I personally would like to see us try to hit that window of
opportunity and evolve XML along a middle path.
|
