[Phoenix] Re: Bug in source node retrieval

[Comiotto Thomas]

Hi Andi

>
> Hmm, why is this not standards compliant? I believe that a document
>
> <foo xmlns="foo.com/1.0">
>  <bar/>
> </foo>
>
> is perfectly ok, no?
>

yes you're right.


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

However, I am sidelined a bit ATM so you will have make the changes 
needed yourself - according to your very own personal preferences:)

Just make sure that it still works with documents that use the null 
namespace.

--
Bests
Thomas