Re: case in Selectors API

Trying to work out the logic of this document, and failing. Assuming no
normalisation and no real case folding, then namespaces prefixes should
always be case sensitive.

which is what they seem to imply in
the text:

 "To resolve namespace
prefixes, if there was an    NSResolver
object provided, user    agents must pass the prefix,
preserving case, to the    lookupNamespaceURI()
   method. User agents must handle prefixes case   
sensitively."

Then further below they say:

"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."

On one hand they want case sensitivity. On the other they tell
implementers they can do whatever they want: case sensitive or case
insensitive. Not sure were this leaves end users as distinct from
implementers.

If case insensitivity is a possibility, warnings
about need for normalization and case-folding should be included.

Andrew

On Fri, February 8, 2008 4:10 am, Mark Davis wrote:
> I agree on both counts.
> 
> On Feb 7, 2008 8:29
AM, Addison Phillips <addison@yahoo-inc.com> wrote:
> 
>>
>> All,
>>
>> I note that we
have another example of case-mapping woes in the
>> Selectors
API document. This case disturbs me and I think we should
>>
submit a comment. The document is: http://www.w3.org/TR/selectors-api/
>>
>> The text in question is:
>>
>> --
>> 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.
>> --
>>
>> My problems with this text are:
>>
>> 1.
It seems to me that the WebAPI is doing implementers a disservice
>> here. If they would otherwise have required case-insensitivity
except
>> for the requirement that implementers of NSResolver
understand Unicode
>> case folding, then ignorance of Unicode
case folding shouldn't be a
>> barrier to requiring
case-insensitivity. I see no reason why a Spec
>> cannot
require something if it is both well-documented and necessary,
>> which appears to be the case here.
>>
>>
For that matter, it isn't strictly a "Unicode" problem (as
implied by
>> the above): it is a general problem of
case-normalizing text. Namespace
>> prefixes are not limited to
ASCII, and implementations of Selectors API
>> need to deal
with that fact.
>>
>> 2. Case-insensitive mapping is
not completely sufficient anyway. No
>> mention is made of
normalization. If there is something they are not
>> going to
require but should mention, it would be Unicode normalization
>> (see CharMod-Norm). Binary comparison of Unicode strings for
character
>> equivalence requires this normalization
over-and-above case-folding.
>>
>> Regards,
>>
>> Addison
>>
>> --
>> Addison Phillips
>> Globalization Architect --
Yahoo! Inc.
>> Chair -- W3C Internationalization Core WG
>>
>> Internationalization is an architecture.
>> It is not a feature.
>>
>>
> 
> 
> --
> Mark
> 


-- 
Andrew Cunningham
Research and Development Coordinator
Vicnet
State Library of Victoria
Australia

andrewc@vicnet.net.au