Norm, I'm really shocked at your statement that "More Unicode characters are allowed in text" in XML 1.1. I really thought you knew better than this. I expected the footnote would clarify your point, but it just made it worse. Sadly there has been a lot of FUD spewed on this issue by people trying to justify XML 1.1. The benefits of XML 1.1 are so minscule and the costs so high, that the only way to justify it is by pretending it solves a problem that doesn't actually exist.

Let's be clear about one thing: XML 1.1 enables NO new genuine characters in XML text. The only new characters added are a few C0 controls. Every single human legible character in Unicode 3.0, 4.0, and any future version is legal in text (element content, attribute values, processing instruction data, and comments) in XML 1.0. There is nothing in XML 1.0 that makes it inadequate for writing Amharic, Burmese, Thaana, Yi, Tengwar, or any other language that can be written with Unicode 3.0, 4.0, or later.

The advances in XML 1.1 are solely about XML names. They have nothing to do with XML text, except for one tiny intersection of DTD validated ID-type attributes, but you don't think DTDs are very relevant so that's not a huge win. No languages are discriminated against by XML text. XML 1.1 might be useful to someone who wants to write ther markup (not their text but their markup) in Amharic, Burmese, Mongolian, Cambodian or any of a few other more obscure languages. Anybody who doesn't need to do this has nothing to gain from XML 1.1. And anybody who wants to write a Mongolian web page in XHTML or a Burmese technical manual in DocBook can do it just fine with XML 1.0.

"The rest of the XML 1.1 changes were either unnecessary or feature creep, IMHO, but they’re harmless."

The trouble is, they are not harmless, changing the white space rules in what was supposed to be a minor point increase was always going to inflict real pain. especially adding characters outside the ascii range to the white space set means that even if you know your doc is in utf8 you can't really use standard 8bit text processing tools very easily on the file (which after all is one of the main points of utf8).

If 1.1 had stuck to changing the name char rules to being workable with all future unicode versions not just 2.0 it would (or might) have had a better chance of success.

You may consider me duly chastised, Elliotte. And a little red in the face. I shouldn't have gotten that wrong.

You're absolutely right, of course.

It is not hard to "allow a different suite of additional characters in names" for XML 1.1. But this behaviour cannot be introduced to RELAX NG 1.0 without possibly breaking conformant implementations.

It is certainly possible to create RELAX NG 1.1 to address XML 1.1. This is good for I18N and may be bad for the promotion of RELAX NG. How do you feel?

Allowing non-ASCII in element and attribute names seems politically correct, but are there known cases of people actually using non-ASCII element and attribute names with XML 1.0? All widely-used well-known vocabularies have all-ASCII element/attribute names.

With many European languages there's the issue of NFC and NFD representations being different XML names. A bug induced by NFC vs. NFD difference in element/attribute names is not a bug I'd like to spend time tracking down.

By the way, I am very sure that a lot of Japanese XML users heavily use Japanese characters for element and attribute names. In fact, an XML project of a Japanese ministry (which I am involved in) will very heavily use Japanese names and will use almost no ASCII names.

So, I am not saying XML 1.1 is useless. But, for RELAX NG to use XML 1.1, we need a new version of RELAX NG.

Now, I may be jumping into the discussion a little late, but I'd like someone to clarify something. What the hell is RELAX NG and why should the advancement of XML to version 1.1 have such a marked impact? I understand that if one used the newly supported Unicode characters in the XML names where they are restricted such as "element type names, attribute names, enumerated attribute values, processing instruction targets, and so on"* they documents would not be backwards compatible with an XML 1.0 processor. The only thing the Relax NG web site really told be was that it was a schema language for XML. I can understand why the new features of XML 1.1 would not allow it to validate with the current versions of RELAX NG or XML Schema 1.0; however, as the language evolves I see no reason why the schema languages built around it shouldn't evolve as well.

I can really relate to what MURATA Makoto said. I have worked with developers from Japan on a number of occasions and they are very adamant about using their native characters in XML names and anywhere else they can for that matter. Localization is becoming a real issue as more and more people move toward electronic documents. I don't see why anyone should be forced to work outside their native language and character set because the people who designed XML 1.0, XML Schema 1.0, and Relax NG didn't have the foresight to see beyond Unicode 2.0.

On Aaron Winters comments: when XML 1 was designed, it allowed all characters in data (except for characters that are special purpose characters used for driving teletype printers {such as the backspace control character} or with obscure Unicode semantics. However, it restricts the characters allowed in names to a sensible set, based on the version of Unicode available at the time.

As Unicode is updated, there are several approaches possible for updating XML:

1) leave it alone

2) update the detailed lists of allowed characters

3) move to excluding characters that are unwanted and allowing all the others

4) move to use the Unicode properties for each character to decide which are good

The trouble with 1) is that XML needs to have best practise internationalization: the more central it is to computing, the more that any limitations increase the burdon's on people who are left out. On the other hand, there is a time for everything: I would prefer if W3C went onto a timed release strategy, and told everyone to expect an updated spec every 5 years and to expect to change to it.

The trouble with 2) is that then the XML WG has to put out updates to XML to track Unicode, and they have better things to do than maintaining XML, apparantly.

The trouble with 3) is that you lose some fine-grain ability to detect transmission problems. And who is to say that Unicode may not add an inapropriate character that you have to cater for independently anyway? On the other hand, it lets you work in ranges which may be more efficient for computation. 3) is pretty much the route taken with XML 1.1.

4) is probably the way I would have liked. It takes decisions out of the hands of the XML Working Group. All that needs to happen is a slight change in understanding that a well-formed name means "well-formed according to the Unicode library of the particular platform we are using", which is certainly good enough now that Unicode 4 is so widely deployed.

On top of this comes the question of whether such a change should be enough force a version-up of the XML number: this version-up alone is enough to break almost all XML processing software independent of anything else.

The first thing the XML WG (or indeed, the W3C) should do IMHO is to have a workable version number policy for implementers: such as "A version m.n processor must reject any document with an m greater than its own. A version m.n processor may reject any document with m less than its own. For documents with the same m as the processor, a version m.n processor must accept all documents with an n less than or equal its own, and will accept any document documents with an n greater than its own unless some other error is found." In other words, allow an XML 1.0 processor to read an XML 1.1 document an only barf when something is actually wrong. At the moment, the version numbers is a bar to well-managed updates of standards.