Re: [xml-dev] Ten Years Later - XML 1.0 Fifth Edition?

[Michael Champion <mc@xegesis.org>]

It does take a bit of hairsplitting to conclude that 1.0.5 is legitimately an erratum rather than a new version. But what's a better way forward?  I see the XML 1.0.5 proposal as treading a very narrow path with an abyss on each side: On one side is the status quo, which arbitrarily limits XML names (and id attribute values, I learned today from Richard Ishida); on the other side is the failed experiment of revising XML with a new version, and the reality that the current edition of XML 1.0 insists that the versioninfo value be '1.0'. (Thus, just making in an actual revision  'XML 1.0.5" rather than "XML 1.0 5th edition" creates another nasty set of problems).

 

There is no good solution here, so we need to figure out which alternative is the least bad.  There are certainly plenty of people around W3C who find the status quo unacceptable.  There are even more who found XML 1.1 unacceptable because of the real-world interoperability problems it causes.  The 1.0.5 path is a bit scary and has all sorts of hypothetical interop problems, but it's not at all clear that it will cause significant pain for implementers (even those with hundreds of millions of users), and user pain will be felt only by those actually exploiting the 1.0.5 changes.  In other words, it is a classic W3C outcome - an issue resolution that hardly anyone actually likes, but nobody finds completely unacceptable.

 

Nobody is particularly happy with the W3C process -- being consensus-driven, it almost inevitably creates weasel-wording that insiders can live with but outsiders are a bit mystified by. Still, that consensus tends to capture what actually works across platforms and products, at least after a few years of testing, profiling, and disambiguating..

 

I'm not sure how our company will vote in the AC on this (I only "own" rather than actually control the decision). So far, the benefits of this PER seem to outweigh the actual costs, but I'd be very interested in hearing about anyone adversely impacted if this became an edited Recommendation. Are there real-world scenarios where current applications break? (I don't mean corner cases in implementers test suites, I mean actual applications that somehow depend a parser rejecting documents that would be accepted under the proposed edited recommendation). Are the potential interoperability problems this is likely to create anywhere near as great as the ones we deal with today (e.g. the numerous challenges of XSD-driven databinding)?  Finally, how do the actual costs of XML 1.0.5 compare to the benefit of not having to worry about XML 1.1 anymore? 

 

My personal bottom line is that this revision offers the only real benefit that 1.1 had at a small fraction of the actual cost, albeit with a non-negligible aesthetic cost. That's about as un-bad as we can realistically hope for.

"Simon St.Laurent" <simonstl@simonstl.com> wrote:

> I haven't had faith in the W3C's process for a very long time, but this 
> kind of hair-splitting seems counterproductive at best. It seems 
> extremely clear that both supporters and opponents of the proposal 
> regard it as indeed something new.