W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

[comments] Selectors-API

From: Addison Phillips <addison@yahoo-inc.com>
Date: Fri, 15 Feb 2008 10:24:14 -0800
Message-ID: <47B5D8CE.7030603@yahoo-inc.com>
To: public-webapi@w3.org
CC: public-i18n-core@w3.org

Dear Web API WG,

I am writing on behalf of the I18N WG. I apologize for the lateness of 
our comments.

We have three related comments on the Selectors-API document [1], as 

1. Require case sensitivity?

The document is unclear about about case sensitivity vs. case 
insensitivity. We note that XML namespaces are supposed to be case 
sensitive, as are most of the W3C document format namespaces, and there 
are requirements in the document for case sensitivity. However, there 
are also examples in the document discussion case insensitivity. The 
document is ambiguous about whether case sensitivity is a good thing or 
not and we question whether case insensitivity should be allowed at all.

2. If case insensitivity is allowed, require Unicode case folding.

In Section 2.1 we find these notes:

Note: The case sensitivity of namespace prefixes is effectively 
determined by the implementation of the NSResolver object that is used 
to resolve the namespaces.

Note: In Unicode, caseless matching requires both strings that are being 
compared, to be case folded prior to performing a binary comparison 
[CaseMap]. However, since case folding is not the same as simply 
uppercasing or lowercasing both strings and because the comparison is 
being performed by the NSResolver object implemented by the author, this 
specification cannot require case insensitive namespace prefixes.

These correctly describe the fact that caseless matching cannot rely on 
a call to toupper() or tolower() functions.  However, later in Section 
2.1 we find:

For convenience, in ECMAScript, the NSResolver may also be implemented 
as a function. In the above example, namespace prefixes are resolved 
case sensitively. If case insensitve namespace prefixes are desired, it 
is possible to implement this in the resolver by altering the case of 
the prefix before comparison.

This incorrectly identifies caseless matching as using exactly this sort 
of pre-normalization.

The I18N WG does not agree with the conclusion that this specification 
"cannot" require case insensitive namespace prefix comparison due to the 
need for Unicode case folding. We note that case-folding issues are not 
limited to Unicode. They are inherent in caseless comparison. NSResolver 
authors adhering to Selectors-API are in a position to implement 
case-folding correctly. The algorithm is well-understood and 
well-specified. Since Selectors-API allows for non-ASCII namespace 
prefixes, caseless comparison really ought to require Unicode case folding.

If, for some reason, you wish to require NSResolvers to be case 
sensitive but provide guidance for those who wish to use it in a 
caseless manner, you should ensure that your examples reference Unicode 
case folding.

3. Add Unicode normalization as a requirement.

The I18N WG notes that comparison of namespace prefixes, in order to be 
reliable, require Unicode Normalization Form C. For more information, 
see CharModNorm [2]. Please note that this comment applies to both 
caseless and case sensitive comparsion!


Best Regards for I18N Core WG,


[1] http://www.w3.org/TR/2007/WD-selectors-api-20071221/
[2] http://www.w3.org/TR/charmod-norm
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.
Received on Friday, 15 February 2008 18:24:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:59 UTC