[Phoenix] Re: Bug in source node retrieval

[Comiotto Thomas]

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


--
Bests
Thomas





>
> I can't see where the error could be. E.g. I have a location path 
> "/entry/id/." in the XSLT view, and a corresponding "/entry/id" in the 
> source. Nevertheless, it can't be found.
>
> Maybe you could have a look at it. It's in the latest revisioin. Go to 
> the Atom demo page, and edit an Atom entry.
>
>>> Furthermore, location paths crossing namespace borders do not seem 
>>> to work (at least I believe so, I could not test it because of the 
>>> bug above), e.g. "/entry/content/div/ul/li",
>> The source tagger mechanism generates qualified path segments only. 
>> Namespace crossing did work with all examples I did test against. 
>> There might be a problem with documents that use a default namespaces 
>> without specifying a ns prefix for that namespace. Check the source 
>> comments re namespace resolving.
>
> Ok.
>
>>> where <entry> and <content> are in the Atom namespace and the rest 
>>> is in the XHTML namespace. I believe this does not work because the 
>>> location path is as seen above, and therefore does not carry any 
>>> namespace information.
>>>
>>> Also, I did not understand what you mean with namespace aware vs. 
>>> namespace unaware in the code. Is this related to the behaviour as 
>>> depicted above?
>> This only related to the xpath query generated by 
>> getSourceXPathForXHTMLNode:
>> aware:
>> foo:bar/bar:foo/@bar
>> unaware:
>> *[local-name()='bar']/*[local-name() = 'foo']/@bar
>> Not implemented yet. Ment as a fallback for situations where source 
>> node retrieval does not work because of namespace issues -
>
> Ok, cool!
>
> -- 
> Kind regards,
> Andi
>