W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2009

Re: [CSS21][css3-namespace][css3-page][css3-selectors][css3-content] Unicode Normalization

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 02 Feb 2009 16:14:24 -0500
Message-ID: <49876230.5000501@mit.edu>
To: "Phillips, Addison" <addison@amazon.com>
CC: Mark Davis <mark.davis@icu-project.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, "www-style@w3.org" <www-style@w3.org>

Phillips, Addison wrote:
> The question here is one of interpretation. Anne points out that, at
> least theoretically, it is possible to create XML document schemas
> that define two semantically identical names that are encoded using
> different code point sequences. This, of course, is an Extremely Bad
> Idea, since, among other things, such a document might not live
> through a transcoding to another character encoding or other forms of
> processing. Although Anne pointed to XML 1.1, in fact, XML 1.0 5e
> also includes the same recommendations:
> 
> http://www.w3.org/TR/xml/#sec-suggested-names
> 
> The real question is: what feature is more important to preserve? The
> non-normalizability of XML names (which is deprecated anyway)?

I couldn't care less about non-normalizability of XML names per se, but 
you indicated that any data that will be communicated to the server 
can't be normalized.  You said this in the context of form textfields, 
but there's nothing particularly special about those that I can see... 
Any data exposed via a DOM API, whether it be form input values or 
XML/HTML tag localNames can be sent to the server, right?

Again, it feels like I'm missing something here.

-Boris
Received on Monday, 2 February 2009 21:15:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 February 2009 21:15:58 GMT