Re: [comments] Selectors-API

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/

Received on Saturday, 16 February 2008 06:10:21 UTC