[Phoenix] Re: Bug in source node retrieval

[Comiotto Thomas]

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. 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. 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;)

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.

--
Bests
Thomas





>>>> - or we insert dummy default ns prefixes before tagging the source.
>>>> e.g.
>>>> <foo xmlns="foo.com"/>
>>>> <foo xmlns="foo.com" default:xmlns="foo.com"/>
>>>> /default:foo -> match.
>>>
>>> Yes, and no. If we know which the default namespace is, our 
>>> namespace resolver can simply take this into account, and we could 
>>> issue queries like "/defns:foo" on a document like the one I've 
>>> depicted above (our namespace resolver simply resolves "defns" to 
>>> "foo.com").
>> IIRC I implemented it this way in the first place but I found tagging 
>> the source with qualified location paths was much more straight 
>> forward (no need to add defns: prefixes and the corresponding ns 
>> resolver when later assembling and executing the xpath expression), 
>> therefore I replaced it.
>> We can either drop this approach or patch a temporary copy of 
>> documentDOM to contain xmlns:defns="defnsURI" (if a default namespace 
>> prefix is lacking) before applying sourcetagger.xsl.
>> To support multiple unprefixed default namespaces, I guess using the 
>> ns resolver approach would be better. One could also patch a 
>> temporary copy of documentDOM to contain qualified names only 
>> (including multiple/different defnsXY: prefixes) before applying 
>> sourcetagger.xsl of course. That would be trivial to write and would 
>> do the job too.
>
> Hmm, you mean walking the DOM tree and adding prefixes if needed? This 
> would be transparent and not need a separate namespace resolver.
>
>> However, I am sidelined a bit ATM so you will have make the changes 
>> needed yourself - according to your very own personal preferences:)
>
> Sure, no problem.
>
>> Just make sure that it still works with documents that use the null 
>> namespace.
>
> Well, I just like to get it right. ;)
>
> -- 
> Kind regards,
> Andi
>