[Phoenix] Re: Bug in source node retrieval

[Andreas Wuest]

Hi

On 19.9.2006 11:29 Uhr, Thomas Comiotto wrote:

> Hi
> 
>>
>> Source node retrieval does not work for e.g. the XSLT view for an Atom 
>> entry. Although I have a location path, e.g. "/entry/updated/", 
>> getSourceXPathForXHTMLNode() cannot retrieve it from the source 
>> document, and always returns null (although this element is indeed 
>> present in the source).
> 
> Check if the xhtml document is tagged correctly - otherwise review styles

The document is indeed tagged correctly. Don't know what you mean with 
review styles. The transformed document is ok as well.

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

The transformed docuemnt also uses a default namespace without prefix.

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