Addison Phillips wrote:
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.
The spec does require user agents to handle prefixes case sensitively.
The original reason for the note was because Selectors required the use
of case insensitive prefixes and it was added to explain why this could
not be done, since the implementation of the NSResolver object is out of
the control of the user agent. However, this issue has since been
resolved by the CSSWG, and Selectors now allows either.
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.
--
I have replaced those notes with this one:
Note: Although prefixes are case sensitive, there are no restrictions
imposed by this specification on how the implementation of the
NSResolver object may handle them internally. Thus, while the resolver
may handle them case insensitively, such an approach is effectively
the same as declaring all case variants of the prefix with the same
namespace URI.
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.
I have added a note to the example stating the following:
Note: This is not a proper implementation of caseless matching in
Unicode, which requires both strings that are being compared to be
case folded prior to performing a binary comparison [CaseMap].
However, this is a sufficient approximation for prefixes that are
restricted to characters, such as those in the US-ASCII subset, for
which simply converting both strings to lowercase and comparing
returns the correct result. If desired, an implementation of the full
case mapping algorithm is left as an exersise for the reader.
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.
Since the NSResolver object is intended to be implemented by authors,
rather than user agents, it is unrealistic to expect authors even
attempt to adhere to such a requirement. Implementing the case mapping
algorithm in JavaScript, for example, is not trivial.
The algorithm is well-understood...
I can assure that it is not well understood, nor even known about, by
many of the intended implementers of the NSResolver objects; namely
JavaScript developers.
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.
I believe the note I added to the example sufficiently addresses this
request.
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!
I am unsure how to deal with this issue as this stage. I cannot require
the NSResolver object to perform the normalisation, and I need to
evaluate the impact of requiring the UA to perform the normalisation of
the prefix before passing it to the resolver. Feedback from
implementers on this issue would be useful.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
