João Eiras wrote:
On , Jonas Sicking <[EMAIL PROTECTED]> wrote:
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.
You misread. That was the list of issues I outlined on the dom mailing
list, back in 2007.
Of course we can workaround them, and we should.
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.
Having what ? Since when did I suggest creating elements ?
That list of suggestions were about chaging NSResolver behavior.
Doh! I got to the "a element" part and then misread the rest with faulty
assumptions. My bad. I agree with the above.
You may go to
http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html for
code samples.
Unfortunately I don't think we can change how XPath parses things since
there is already code out there that might rely on the current behavior.
Might be worth looking into though.
/ Jonas
