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.
