Re: [selectors-api] Selectors API comments: section 2.1

Boris Zbarsky wrote:
> Comments on 
> http://www.w3.org/TR/2007/WD-selectors-api-20071221/#nsresolver-interface
> 
> * What is the expected behavior of lookupNamespaceURI when a null 
> DOMString is passed in?  Should it match the behavior when an empty 
> string is passed in?  Note that in ECMAScript, for example, the tests:

This is not an interoperability concern because the NSResolver interface 
defined here is not implemented in any object by the user agent, but 
rather by the author of the script.  Additionally, while resolving 
namespaces, the user agent will only ever invoke the method with the a 
string (either the prefix or empty string for the default NS).

> * The text "it MUST do either of the following" at the end of the second 
> paragraph after the interface definition would be better written as "it 
> MUST do one of the following".

This has been changed to "it must:".

> * It's not clear what "similar constructs" means in the phrase "and 
> other languages that allow similar constructs".  Does this mean 
> "first-class functions", or something else?

The statement has been removed.

> * It should be clarified that if the NSResolver is a Function, invoking 
> the function with a single string argument should replace calling the 
> lookupNamespaceURI method.  I believe the DOM Level 2 Events ECMAScript 
> bindings for EventListener have some language that could be reused here.

This has been clarified by defining that ECMAScript implementations must 
support the NSResolver being implemented as both an object and a 
function, and, if passed a function, that it must invoke the function 
itself instead of the lookupNamespaceURI method.

> * I'm not sure what the "or does not return a DOMString" text in the "To 
> resolve namespace prefixes" paragraph means.  Does this mean that if, 
> say, an ECMAScript an object with a toString() method is returned this 
> method must not be invoked and instead the namespace should be treated 
> as unresolvable?

This has been addressed by defining that if any object other than a 
string is returned, it must first be converted to a string.

> * What does "or equivalent" refer to in the "To get the default 
> namespace" section?  Why is that not applicable to the "To resolve 
> namespace prefixes" section?  I would expect empty string handling to be 
> identical in both sections.

Because an empty string isn't a valid namespace URI and because a prefix 
can't represent the null namespace, an exception is thrown when 
resolving a prefix.  However, since the default namespace doesn't need 
to be defined, it's easier to just say that the empty string resolves to 
the null namespace than to throw an exception.  That's why the handling 
is different.

> * It might make sense to talk about "callers" in this section instead of 
> "user agents", though I'm OK with the existing language if the change is 
> judged to be too confusing for non-technical readers of the specification.

The spec now refers to implementations instead, based on your previous 
comment in another mail.

> * In the example paragraph starting with "For convenience", there is a 
> missing 'i' in the word "insensitive".

Fixed.

Please see the latest version of the spec in CVS to review the changes.
http://dev.w3.org/2006/webapi/selectors-api/

Please let me know if you are not satisified with any of these responses 
or changes.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Thursday, 14 February 2008 13:35:28 UTC