Re: [selectors-api] Investigating NSResolver Alternatives

Joćo Eiras wrote:
> 
> Hi !
> 
> I vote for having a new light weight object to completely replace the 
> current NSResolver, and then apply it to other DOM specs namely the 
> XPath DOM.
> 
> I had some of the problems we're discussing with the XPath DOM API, and 
> obviously the same apply here.
> I exposed my problems at the dom mailing list, but my comments were 
> dismissed completely
> http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html
> 
> The problems I outlineed with NSResolver are summarized to the following:
>  - a element with no prefix is assumed to be
>    in the namespace with null uri. You can't
>    change this behavior.

This is not true. We can just define that unprefixed names call into the 
NSResolver with an empty string, and whatever the NSResolver returns 
will be used as prefix.

>  - a element with a prefix MUST be in a
>    namespace with non null namespace uri, else
>    returning empty string from lookupNamespaceURI
>    results in NAMESPACE_ERR being thrown

Again, this is not true. We can just define that returning the empty 
string means to use the null namespace.

null is the value that's supposed to be returned when no namespace is 
found and NAMESPACE_ERR should be thrown.

Even the resolver returned from createNSResolver is horribly 
underdefined and so we could make it follow the above rules without 
breaking any specs.

> I proposed the following changes:
>  - a element with no prefix would result in
>    lookupNamespaceURI being called with the empty
>    string, and the resolver could return a default
>    namespace, or return null (or empty string) to
>    imply the null namespace
>  - a element with prefix would result in
>    lookupNamespaceURI being called with the prefix
>    and the function could either return null
>    (or empty string) to imply the null namespace,
>    or it could return a fully qualified uri.

Having to create an element whenever you want to resolve some custom 
namespaces seems like a horrible hack, and awefully complicated to use.

Say that I wanted to find all elements in the "myNS" namespace, using a 
NSResolver I would do:

doc.querySelectorAll("*", function (pre) {
     return pre == "" ? "myNS" : null;
   });

With your proposed solution I'd have to do

doc.querySelectorAll("*",
   document.createElementNS("myNS", "dummy"));

This looks sort of ok, but still very strange to have to use the dummy 
name. However, if i'm using two namespaces in an expression i'm in a 
world of pain. Compare

doc.querySelectorAll("a:*, b:*", function (pre) {
     return pre == "a" ? "myNS" :
            pre == "b" ? "myNS2" : null;
   });

vs

e = document.createElement("dummy");
e.setAttributeNS("http://www.w3.org/2000/xmlns/",
                  "xmlns:a", "myNS")
e.setAttributeNS("http://www.w3.org/2000/xmlns/",
                  "xmlns:b", "myNS2")
doc.querySelectorAll("a:*, b:*", e);

How many people even know the proper namespace for the xmlns attribute? 
Did you?

On top of that we can't really change how DOM-XPath works given that 
there are implementations for the spec with pages out there depending on it.

/ Jonas

Received on Friday, 15 August 2008 22:03:45 UTC