- From: Addison Phillips <addison@yahoo-inc.com>
- Date: Fri, 15 Feb 2008 10:24:14 -0800
- 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 follows: 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, Addison [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