[Phoenix] Re: Bug in source node retrieval

[Andreas Wuest]

Hi Thomas

On 19.9.2006 23:09 Uhr, Comiotto Thomas wrote:

> Hi Andi
> 
>> Ok, fine! :) I've already started to doubt myself.
> 
> You know, I have doubts myself. So here's a short summary for that matter.
> 
> http://www.w3.org/TR/xpath#node-tests says:
> 
> "A QName in the node test is expanded into an expanded-name using
>    the namespace declarations from the expression context. This is the
>    same way expansion is done for element type names in start and
>    end-tags except that the default namespace declared with xmlns is
>    not used: if the QName does not have a prefix, then the namespace
>    URI is null (this is the same way attribute names are expanded). It
>    is an error if the QName has a prefix for which there is no
>    namespace declaration in the expression context."
> 
> In my understanding this means that
> 
> <foo xmlns="bar.com">
>   <bar/>
> </foo>
> 
> is fine (so yes, you're right), but at the same time it's somewhat 
> pointless.

Well, yes, from an XPath query point of view. For all other purposes, 
it's of course sensible to declare the namespace (e.g. for validating).

> Because in xpath (and xslt for that matter) /foo/bar will 
> match the null namespace by spec (if not its a bug in the processor). 
> The tricky part is that after declaring a default namespace and not 
> specifying a prefix for it, elements in that ns become unaccessible for 
> xpath processors, except if you write a nsresolver that resolves a fake 
> prefix xmlns of a given context and use that fake prefix in the xpath 
> expression.

Exactly.

> Re resolver: I guess this would require manual ns lookup for 
> every segment of a given xpath expression. I did a websearch for a 
> generic resolver that does this some weeks ago but didn't find anything 
> - so I got somewhat dubious if I just missed the point. But now I think 
> if we write such a resolver (including code that rewrites a given xpath 
> expression, argh!) others would probably also be interested in using it;)

I am not sure what you are referring to here. If you are simply thinking 
about a custom namespace resolver which we can pass to evaluate(), which 
will e.g. resolve a prefix "thomas" to "thomas.com/spaceynames" in a 
query "/thomas:foo/thomas:bar", then this is easy. In fact, we are using 
custom namespace resolvers in most places of Yulup (see e.g. 
appparser09.js line 71, or for an even fancier one, common.js line 292).

Or maybe I misunderstood.

> Anyway, given the somewhat confusing situation in this area I think it 
> would also be legitimate to just lack support for documents that use 
> unprefixed default namespace - better to say: to let users fallback to 
> non-ns aware mode for this (hopefully rare) case.

Hmm, well, I'm a bit wary about this. Because e.g. Atom entries are 
mostly like this (and falling back to namespace-unaware mode is no 
option, if I understand that mode correctly, because Atom entries can 
contain mixed namespaces, e.g. the can contain XHTML markup inside 
<atom:content> elements).

So I better go and implement this... ;)

-- 
Kind regards,
Andi