Re: XPathNSResolver issues

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

> * Joćo Eiras wrote:
>> This is a issue, severe from my point of view, as you cannot reuse the
>> same logic to retreive those nodes.
>> We need to find a way to drop the prefixes and still being able to  
>> select
>> the same nodes.
>
> I don't understand your argument here. As you point, you can simply use
> prefixes and have them resolved properly by a custom namespace resolver.
>

I'm working aroudn the xpath dom and I cannot change the xml source nor  
the expressions
because they're out of my control.
Good to know about the xpath 2.0 default namespace support, but this issue  
with xpath 1 is a serious limitation.
And again, the xpath expressions and xml are out of my control.


>> The xpath dom spec clearly left out this use case after specifing that  
>> the
>> result of passing null or the empty string to lookupNamespaceURI should  
>> be
>> undefined. How would then one query the default namespace ?
>
> I am not sure doing that would make much sense, but you can simply give
> it a prefix, use that prefix in the expression, and have your resolver
> properly resolve it (besides, I am not sure which default namespace you
> are looking at, there may be one for every element in a document).
>
>> If there's a nsresolver, then node names without prefix in the  
>> expression
>> are in the namespace returned by loopupNamespaceURI with a null or empty
>> string parameter. This would be backwards compatible with the current
>> spec, because applications currently do not passed empty string or nulls
>> to loopupNamespaceURI, so this would be an harmless extension.
>
> We might be making such changes to accomodate XPath 2.0 which has a
> notion of a default namespace for an expression, but I don't see why
> this would make sense to accomodate your issue.

Received on Thursday, 11 October 2007 17:53:01 UTC