W3C home > Mailing lists > Public > www-style@w3.org > October 2006

Re: [css3-selectors] Namespace name lookup mechanisms

From: Bert Bos <bert@w3.org>
Date: Sat, 07 Oct 2006 17:11:09 -0700
Message-ID: <4528421D.307@w3.org>
To: www-style@w3.org

Bjoern Hoehrmann wrote:
> Hi,
> 
>   Simon Pieters uncovered a problem with namespace prefix handling in
> the Selectors Working Draft when reviewing the XBL2 Working Draft. It
> is currently left to higher level specifications how to look up the
> namespace name that corresponds to a prefix in a selector. This lack
> of a definition results in errors in specifications that use selectors,
> for example,
[...]
> As this is highly undesirable, the Selectors specification should both
> explain this problem and address the common cases directly. A possible
> solution would be as follows: specifications must define a lookup mech-
> anism. If the mechanism is an algorithm, the Selector implementation
> must pass the prefix (transformed to lower-case) to the algorithm. If
> the mechanism is a hash with case-insensitive keys, the key that equals
> the prefix identifies the namespace name. If the mechanism is a hash
> with case-sensitive keys, the keys are put in some order and the first
> key that matches the prefix case-insensitively identifies the namespace
> name (the order would have to be defined). Specifications may define
> other lookup mechanisms. If no mechanism is defined, or the mechanism
> fails to identify a namespace name, the given prefix is considered not
> declared for the purposes of the specification.

I think it's a good idea for the Selectors spec to say explicitly that 
the namespace prefixes are case-insensitive, but it has no business 
saying anything about canonicalization, APIs or the scope of prefix 
declarations.

Inside CSS, the scope is defined by the Namespace module, while 
canonicalization and APIs are not needed by CSS and thus not defined.

Some other technology that uses Selectors can define these aspects any 
way it likes: case-preserving or not, normalizing or not, lexical or 
dynamic scope. It would be good if two similar APIs made similar 
choices, but the Selectors spec doesn't need to say what those choices 
should be.



Bert
-- 
   Bert Bos                                ( W 3 C ) http://www.w3.org/
   http://www.w3.org/people/bos                               W3C/ERCIM
   bert@w3.org                             2004 Rt des Lucioles / BP 93
   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Thursday, 19 October 2006 13:06:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:47 GMT