W3C home > Mailing lists > Public > www-tag@w3.org > June 2004

Re: xml11Names-46

From: Jacek Kopecky <jacek.kopecky@deri.at>
Date: Sat, 12 Jun 2004 17:28:09 +0200
To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
Cc: www-tag@w3.org
Message-Id: <1087054089.30278.151.camel@Kalb>


I believe it is a bit of a different situation with XML 1.1. In XML
namespaces the change broke actual APIs so it created problems. 

Here, APIs for XML already use UNICODE strings to represent the Names
(the main source of problems, apparently) so supporting additional
characters should be an evolutionary step in any application, if
actually any application checks for the allowed ranges. If I was writing
an XML parser and serializer, I would just use UTF-16 or whatever to
represent UNICODE characters and as long as that can accommodate the new
UNICODE codes, my system would have no problem.

IOW, I believe in layering - when UNICODE is revised to include new
character codes, should every spec that uses UNICODE be revised as well?
Apparently, UNICODE doesn't give us the notion of Name-compatible
characters so XML must create it and be revised, but since SOAP or XML
Schema, for example, use Names, nothing should change for them.

I don't even think DOM should be changed, for instance, except in parser
and serializer parts where the DOM implementation should be able to
indicate supported versions, if that is not already present there.

Rewriting history is bad when you change the intents, but I don't
believe it was the intent of XML Schema 1.0 to limit itself to XML 1.0.
They didn't know there would be XML 1.1 and the changes would be so


On Sat, 2004-06-12 at 15:40, Elliotte Rusty Harold wrote:
> At 2:24 PM +0200 6/12/04, Jacek Kopecky wrote:
> >1) specifications that build on XML should tie themselves to XML 1 or
> >just XML, and already existing Recommendations should issues erratas to
> >that effect;
> >2) it must be clarified in the Infoset specification that it isn't tied
> >to any particular XML version (or XML 1 sub-version);
> In other words, you want to rewrite history. No, this simply will not 
> work. When this has been done (notably with the namespaces in XML 
> erratum retroactively claiming xmlns:prefix attributes are in a 
> namespace) it's been a major hassle, and a source of interoperability 
> issues between different specifications.
> What you suggest might have been a good idea at one point, and if we 
> could go back in time and change the specs before they were released, 
> maybe this would make sense. But obviously we can't do that. Let's 
> not pretend the specs says something other than what they do say. If 
> these specs are incompatible with XML 1.1, then they need to be 
> revised: Infoset 1.1, Schemas 1.1, XPath 1.1, etc. Some of these are 
> already in development.
Received on Saturday, 12 June 2004 11:30:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:42 UTC