[Phoenix] Re: Bug in source node retrieval

[Andreas Wuest]

Hi Thomas

On 19.9.2006 16:15 Uhr, Comiotto Thomas wrote:

> Hi Andi
> 
> 
>> The source document uses a default namespace without prefix, but so 
>> does the calendar example (hmm, I just saw that the calendar example 
>> does not specify a namespace at all).
>>
> 
> Note that with regards to xpath, null namespace does not equal 
> unprefixed default namespace.
> 
> e.g.
> <foo xmlns="foo.com"/>
> 
> /foo -> no match!
> 
> <foo xmlns="foo.com" foo:xmlns="foo.com"/>
> 
> /foo:foo -> match.
> 
> So, we either have to consider documents like the one you have 
> (unprefixed default ns) not standard compliant and therefore buggy

Hmm, why is this not standards compliant? I believe that a document

<foo xmlns="foo.com/1.0">
  <bar/>
</foo>

is perfectly ok, no?

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

Where we start running into problems is with documents like

<foo xmlns="foo.com/1.0">
   <bar>
     <duck xmlns="rubberducky.com/duck">
       <quack/>
     </duck>
   </bar>
</foo>

Because here, we would get back a location path like 
"/foo/bar/duck/quack", but we've lost the knowledge that foo and quack 
are in fact in different namespaces, i.e. the XPath query will fail.


So, we could either assume that the mixed default namespace case does 
never occurs, and simply resolve XPath queries against the default 
namespace, or we have to do something more sophisticated.

-- 
Kind regards,
Andi