(1) It's true that 5th edition doesn't do anything to change namespace names from URIs to IRIs ("internationalised" URIs). But that can be done separately, in a revision to Namespaces 1.0. In any case, XML namespace names are usually just treated as strings, and most software doesn't check that they are valid URIs. I don't really see the problem: even if namespace names remain URIs, that's a minor issue compared with being able to use more characters in element and attribute names. There's no "consistency" between element names and namespace names that needs to be maintaned. And typically a namespace name just appears once in a declaration at the start of a document: it doesn't affect readability in the way that element and attribute names do.

(2) IBM didn't push through "features" to suit mainframe users - they just persuaded the W3C to support the traditional IBM NEL line-end character in XML 1.1. Why anyone else should care about this is beyond me.

(3) The main problem with XML 1.1 is that Microsoft doesn't support it. One reason for that may be that they didn't manage to get support for arbitrary binary data in XML documents; XML is supposed to be a textual format.

(4) All the major XML software producers - including Microsoft - are likely to support the 5th edition changes, so the compatibility problem will be small. It's not as if zillions of XML vocabularies using the new characters are going to appear overnight.

Doesn't that mean that someone is being grossly incompetent with version numbering?

Interesting comment, but I'm going to quibble with you about your fourth point. Just because the "major XML software producers" will presumably support the 5th edition (but how quickly? all at once?), this doesn't mean that developers and customers will upgrade as quickly. Mismatches in data and programs will certainly occur.

Plus, what about the non-commercial side? Will the open-source libraries that perl, python, and similar languages use ge the same speedy update?

I'm not arguing against an upgrade, I just don't think it will be as smooth as you think.

Man, sex is something that's existed since the first of us and you go and blow all your chances in one go by writing this? Couldn't you just have gotten absolutely wasted like the rest of us and boned some ho's instead??

Its overbloated and slow to parse. Get shot of it and go for something a little less universal and more usable where we don't need such high powered servers to process the format.

We had a system written specifically to communicate between three systems using XML, after a substantial performance review and 3 months of alternatives testing, we removed XML and halved our equipment costs. It also meant our application responded somewhat quicker without the bloat-parsing. We now have a system that is less universal (but thats fine, nothing else will even need to communicate in the loop) but significantly faster, and as a bonus decreased the 'carbon footprint'.

XML is for people flunked their parsing course at Uni. It fixes nothing and only pushes the real problems deeper into the part of the solution that no one will talk about.

Exactly! I am constantly amazed why verbose XML is pushed to machine-to-machine communication contexts, even locally when both endpoints are under the control of the same or related design team. The ridiculous <tagsWithLongNames>:s with matched </tagsWithLongnames>:s made some sense when a human was writing XML by hand in a text editor, as was commonly the case at the time SGML was invented (the ancestor of XML, from which most XML features were inherited), but nowadays nobody writes any longer pieces of XML by hand. The convention is nothing more than a waste of bits (and carbon, as you note).

(Or maybe it is a conspiracy by the hardware manufacturers to sell more CPUs and memory...)

".....so you can't have Amharic tags..."

Oh look, the world just failed to end. The words "storm" and "teacup" spring unbidden to mind.

Rule 1: If it ain't broke, don't fix it.

Do you actually work in IT? Surely you know that rule reads "If it ain't broken, fix it until it is!"

Open source tools will quite likely get updated before commercial ones. In particular, the latest release of libxml2 already supports the proposed changes.