Are you saying that we should never have XML 2.0 in the future?
What if HTML would have never evolved from 1.0?
Or Schemas, or CSS, or XSLT ?

Sooner or later there will be a new version and unfortunately this would have happened anyway.

Nobody designed futureproof applications and now it is causing problems?

While XML 1.1 brings virtually nothing to the table, the fact that applications don't understand anything other than 1.0 is a great mistake.

Too bad for the short sighted, too bad.

I have very mixed feelings about XMl 1.1. On one hand I like the closer alignment with Unicode (making XML use it by reference rather than by value, more or less). I think the NEL issue is actually important; Michael Rhys says it "could have been solved by the IBM mainframe by mapping NEL to a whitespace character." Uhh, Unicode says that NEL *is* a whitespace line terminator, why should XML treat it as anything else? It's clearly a bug in XML 1.0, why not fix it sooner rather than later? As for the implication that big bad IBM can afford to hack around this, just think of how y'all in the Hive-Mind react to similar suggestions that Bill G. use a few of his spare billions to clean up various messes that Windows has created .... :-)

But you're absolutely right -- the cost relative to benefit of XMl 1.1 is pretty high. Likewise, allowing all the binary codepoints besides 0x0000 is just pointless, I aggree with Michael.

But what is to be done? Never version XML until something truly important needs to be done? The costs of that will be so high that there will be a temptation to dump XML altogether, or maybe to do with XML what XML did with SGML -- maintain sortof a conceptual compatibility, but not real interoperability except with a lot of effort.

So, I see XML 1.1 as sortof an experiment in whether it can be gracefully versioned, and whether the world can adopt to different versions without excessive pain. If the pain really is great, it should be quietly forgotten, by the world if not the W3C. Still, at least the Xerces people are saying that this is a done deal, ready to use (with the appropriate version checks), very little pain. We shall see, I guess, whether this REALLY inhibits interoperability any worse that all the other stuff out there does -- the different encodings, the wellformed/validating divide, the numerous ambiguities and monumental complexities in the Schema spec, etc.

You use xml 1.1 as a scapegoat because of its weak impact, trying to sustain the ephemeral dream of a one-version format in order not to deal with versioning hell.

Unfortunately, versioning is part of evolution and you have to "futureproof" yourself foreseeing the changes that can affect your applications/standards if/when they occur.

Keep an eye open, not a closed mind.

Let's say, Dare, that in the near future we add capabilities to xml to represent arrays, lists, tables and other collections in xml in an easier way without the repetitive and expensive use of tags...

And suddenly the world applauds such idea for the great benefits it will bring to the data exchange arena...

How your applications/standards would embrace such new version?

Again, don't use xml 1.1 as a scapegoat. I know the benefit was minimum for the headache.

Versioning is needed, and sooner than later we will have to deal with it.