Bjoern Hoehrmann wrote:
* 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?
A bug report would be the appropriate course of action
That doesn't actually help define the behavior, though. I'm happy with
pretty much any definition of the behavior here as long as it's defined.
* 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".
Could you explain why that would be better? Looking at the text, it
seems this would be better written as "MUST do: ...".
With s/ do// that looks great to me. My text was better than the
current text because "either of the following" doesn't make sense if you
don't actually have a choice, which is the situation here.
* 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?
I would suggest to remove this remark.
That would be fine with me.
* 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.
(They don't.)
Indeed. That's very sad. I still think we should do better here.
* 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?
That is my reading. Is that simply unclear because one might have some
other expectation?
Yes. For example, one might expect that anything that can be
stringified is OK whenever a string is needed, which is a common
approach in ECMAScript from what I've seen.
-Boris
