RE: XPath question

Subject: RE: XPath question
From: Mike Brown <mbrown@xxxxxxxxxxxxx>
Date: Fri, 18 Feb 2000 17:37:59 -0700
Toby Ferguson wrote:
> I cannot understand why the following statement is true in 
> the XPath spec:
> 
> "NOTE: The meaning of a Predicate depends crucially on which 
> axis applies."
> [...]
> I just couldn't derive this from my reading of the spec

Here is my reading of the spec.

An XPath expression says where to find the members of a node set by
identifying the locations of nodes *relative* to some initial set of nodes.
It's a "path" because it says, essentially, that to find all the nodes in
the set you want, "start at the nodes that match this pattern, then go in
this direction (along an axis) to all nodes that match this other pattern,
then go in this other direction (along another axis) to the nodes that match
this other pattern..." ad infinitum.

An axis very broadly identifies a set of nodes relative to a context node.
The self axis is the context node itself, the child axis is all the child
nodes of the context node, the parent axis is the node one level "above" the
context node, and so on.

A predicate is a filter for a pattern, reducing the set of nodes matching
the pattern to only those for which the expression in the predicate is true.
Each combination of axis::pattern[predicate] is a location step, and
location steps are separated by /.

For example, when you are following the path along the attribute axis from
one node (hopefuly an element, since other types of nodes won't have
attributes) to some other nodes matching the pattern "foo" (i.e., attributes
named foo), you can use a predicate to say that of those nodes, you really
only want the ones for which the string-value is 'bar':

  attribute::foo[. = 'bar']

This example is pretty straightforward because the predicate isn't filtering
anything that is dependent on the axis.

The note you quoted, though, gives an example of how the semantics of a
predicate can be influenced by the axis. It shows that a predicate can
identify a proximity position of a node relative to a context node. This
concept is perhaps better explained in the first paragraph of section 2.4.
The context node is the node you are at when you are embarking on the next
step.

So let's say you want to go along the preceding-sibling axis to the node
with proximity position 5. How do you know which node that is? It wouldn't
make much sense for it to be, of all the nodes in the preceding-sibling
axis, the 5th one in forward document order, because that means the node's
position is 5 nodes away from the beginning of the document, rather than 5
nodes away from the context node. But if you say it's 5 nodes away in
reverse document order, it will be proximal to the end of the document,
which is what you want since the preceding-sibling axis won't contain nodes
that come between the context node and the end of the document; in effect it
is 5 nodes away from the context node.

So that's my interpretation of why these statements are in the spec, and
also why there are no axes that simultaneously identify nodes that precede
and nodes that follow the context node.

   - Mike
___________________________________________________________
Mike J. Brown, software engineer, Webb Interactive Services
XML/XSL stuff: http://www.skew.org/    http://www.webb.net/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread