Re: XPathNSResolver issues

Hi again, and sorry for the late reply.

First, I'm building a client side script to override a buggy web  
application which relies on a specific proprietary API of Internet  
Explorer to do XPath.
By default, and using selectNodes/selectSingleNode IE looks for nodes by  
matching prefixes, which is what they call XSLPattern. One can change the  
selection language to XPath and it'll behave like the spec, although their  
API is different.

In my case, I do not control neither the xml documents nor the xpath,  
although I can prototype the Node interface to implement the behaviour I  
want. I could try to edit the xpath expressions before theyr evaluated but  
that too error prone.

The issue I'm trying to describe is the following: we can have either a  
null or non-null namespace uri, and also a null or non-null prefix for  
nodes, which combine in 4 use cases.
Having a defined prefix and a non-null namespace uri is well covered in  
the xpath dom spec, and controllable using a nsresolver.
Having a null prefix and null namespace uri is also covered in the spec,  
but it's inflexible. A node without prefix must be in a null namespace uri  
to be selectable, which conflicts with the previous behaviour.

There are two cases missing, which are incompatible, because the spec is  
inflexible about null namespace uris or null prefixes.
1) One cannot choose a node without prefix in a non-null namespace uri.
2) One cannot choose a node with a prefix in a null namespace uri.

This is the issue I'm was trying to describe. The issue is NOT with xpath.  
xpath is fine.
So, my suggestion is simple. For custom nsresolvers do:
1) A node without prefix in the expression is in the namespace returned by  
the nsresolver if null is passed to lookupNamespaceURI, which can include  
a null namespace uri
2) A node with prefix in the expression is in the namespace returned by  
the nsresolver, which can include a null namespace uri

For nsresolver created with createNSresolver
1) lookupNamespaceURI returns the default namespace if a null prefix is  
passed
2) lookupNamespaceURI returns null for unknown prefixes (throwing  
NAMESPACE_ERR can be a choice)

Since these cases are not covered in the current spec, and are simply  
extensions to the behavior before, this is backwards compatible.

My words are spoken. And please don't say that applications are flawed  
simply because the DOM spec does not cover needed use cases. This entire  
issue is not an application design issue, or implementation issue. It's  
purely DOM.

Thank you.



Bjoern Hoehrmann <derhoermi@gmx.net> escreveu:

> * Joćo Eiras wrote:
>> I'm working aroudn the xpath dom and I cannot change the xml source nor
>> the expressions because they're out of my control.
>
> So change the resolver. If you cannot change any of the three items to
> get a working combination, then you have a serious design flaw in your
> application.


Na , Bjoern Hoehrmann <derhoermi@gmx.net> escreveu:

> * Joćo Eiras wrote:
>> I'm working aroudn the xpath dom and I cannot change the xml source nor
>> the expressions because they're out of my control.
>
> So change the resolver. If you cannot change any of the three items to
> get a working combination, then you have a serious design flaw in your
> application.

Received on Wednesday, 17 October 2007 21:43:09 UTC