Re: [xml] xpath expression and namespaces

[Daniel Veillard <veillard redhat com>]

On Tue, May 28, 2002 at 10:58:29PM -0700, Aleksey Sanin wrote:
> and the following XPath expression (in XMLDSig notation):
>
>     <XPath xmlns:bar="http://example.org/bar"; >
>         (//. | //@* | //namespace::*)
>         [
>          ancestor-or-self::bar:Something  and
>             (self::text()  or (namespace-uri() != "")  or
>             (string(self::node()) = namespace-uri(parent::node())))
>         ]
>     </XPath>

  Ouch my head hurts ...

> As you can see, we have nodes instead of namespace in the result nodes 
> set. I looked at
> the xpath.c file and found following comment (that probably explains the 
> above result):
>
>     /**
>      * xmlXPathNodeSetDupNs:
>      * @node:  the parent node of the namespace XPath node
>      * @ns:  the libxml namespace declaration node.
>      *
>      * Namespace node in libxml don't match the XPath semantic. In a 
> node set
>      * the namespace nodes are duplicated and the next pointer is set to the
>      * parent node in the XPath semantic.
>      *
>      * Returns the newly created object.
>      */
>
> My question is: what was the reason for this special namespace nodes 
> processing and can
> we process namespace nodes in the same way as all other nodes in xpath 
> evaluation?

  okay here is the "problem". Both the XPath data model and the Infoset
see each of the namespace in scope for an element as child of this element.
On the other hand libxml tree representation only keep in the tree the 
namespaces declarations (i.e. the equivalent of the xmlns attributes).
So there is no 1-1 mapping between both models, as a result the namespace
in scope list needs to be recomputed when asked, and to be able to return
nodes in the node set (with a parent pointing to the element in scope and
not wherethe namespace was declared) a transcient namespace node is created
just for the returned node set, which will be destroyed with the node set.
Usually xpath namespace nodes queries are unfrequent so this sounds the
best compromise for minimizing changes and ensure XPath compatibility.
  You may have found a bug, getting a smaller test would help :-)

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/