W3C home > Mailing lists > Public > public-webapi@w3.org > April 2007

Re: [selectors-api] How to invoke lookupNamespaceURI?

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 20 Apr 2007 15:52:41 -0700
Message-ID: <46294439.8030707@sicking.cc>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: Anne van Kesteren <annevk@opera.com>, "Web APIs WG (public)" <public-webapi@w3.org>

Bjoern Hoehrmann wrote:
> * Anne van Kesteren wrote:
>> The latest version of the draft (1.14) assumes (in an example) that you  
>> take prefixes from left to right and requires (in prose) that you reuse  
>> the result for each unique (after lowercasing) prefix.
> 
> I think the draft should only define that implementations must not call
> the resolver more than once for any prefix; whether the implementation
> looks up a specific prefix at all or in which order it does so should be
> up to the implementation. As an example,
> 
>   x|y:empty > a|b
> 
> would match no elements, the implementation might notice that before it
> cares about the prefixes, and if it does not, it could reasonably start
> evaluating the selector from either side. In short, defining this would
> expose implementations details for no good reason.

I would say that the same holds true for "must not call the resolver 
more than once" though. Since the proposed solution doesn't give 
deterministic behavior for any given NSResolver anyway, why not simply 
say that behavior in this case too is undefined.

I.e. the behavior of the following NSResolver

var N = 0;
function resolver(prefix) {
   return ['http://myns1.org', 'http://myns2.org][N++];
}

is undefined for "x|y:empty > a|b", so why couldn't it be for
"x|y:empty > x|b".

I think we should say that the resolver should return the same value for 
a given prefix, and that it is not defined how many times or in which 
order the UA calls lookupNamespaceURI.

/ Jonas
Received on Friday, 20 April 2007 22:54:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT