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
