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/
