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

Re: XPathNSResolver issues

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Thu, 11 Oct 2007 19:20:24 +0200
To: Joo Eiras <joao.eiras@gmail.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <idmsg3ds8vsia07ts0j9mvkpts1l63abuk@hive.bjoern.hoehrmann.de>

* Joo 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.

>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.
-- 
Bjrn Hhrmann  mailto:bjoern@hoehrmann.de  http://bjoern.hoehrmann.de
Weinh. Str. 22  Telefon: +49(0)621/4309674  http://www.bjoernsworld.de
68309 Mannheim  PGP Pub. KeyID: 0xA4357E78  http://www.websitedev.de/ 
Received on Thursday, 11 October 2007 19:07:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:59 GMT