Re: [selectors-api] Investigating NSResolver Alternatives

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.
  - 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

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.

These changes fitted well with the specification because these cases were  
either undefined or expected implementations to simply throw exceptions.

I ask you not to make the same mistakes that were done with the xpath dom  
api, because nsresolver currently is fairly broken, and not that much  
useful.

Again, I vote for a new lightweight object, and to allow mixing both  
elements with or without prefixies with null or non null namespace uris.

Thank you.

Received on Friday, 15 August 2008 21:04:03 UTC