[Phoenix] Re: Bug in source node retrieval

[Thomas Comiotto]

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

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

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

--
Bests
Thomas




>
> -- 
> Kind regards,
> Andi
>