W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2007

Re: XPathNSResolver issues

From: Joćo Eiras <joao.eiras@gmail.com>
Date: Thu, 11 Oct 2007 18:45:54 +0100
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <op.tz1nmse3jz3wb9@dragast>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:13 UTC