Re: Re: Re: limiting preceding axis by ancestor

Joerg Heinicke <joerg dot heinicke at gmx dot de> wrote: 

> 
> I thought that this is true, *because* it's a reverse axis. I used
> [1] 
> because I wanted the nearest ancestor. The question for me is "Why is
> 
> the returned nodeset ancestor::foo upside down, so back in document 
> order again?"

Why should there be a question about this? Every node-set *is* (only)
in document order.

The (only) document order of any node-set has nothing to do with the
way a location step is evaluated by an XPath engine. It seems to me
that your confusion stems from mixing these two.

>From the XPath specs (http://www.w3.org/TR/xpath#predicates):

"An axis is either a forward axis or a reverse axis. An axis that only
ever contains the context node or nodes that are after the context node
in document order is a forward axis. An axis that only ever contains
the context node or nodes that are before the context node in document
order is a reverse axis. Thus, the ancestor, ancestor-or-self,
preceding, and preceding-sibling axes are reverse axes; all other axes
are forward axes. Since the self axis always contains at most one node,
it makes no difference whether it is a forward or reverse axis. The
proximity position of a member of a node-set with respect to an axis is
defined to be the position of the node in the node-set ordered in
document order if the axis is a forward axis and ordered in reverse
document order if the axis is a reverse axis. The first position is 1.

A predicate filters a node-set with respect to an axis to produce a new
node-set. For each node in the node-set to be filtered, the
PredicateExpr is evaluated with that node as the context node, with the
number of nodes in the node-set as the context size, and with the
proximity position of the node in the node-set with respect to the axis
as the context position; "


So it's the *proximity position* that is different (only) within a
predicate used in conjunction with a location step, not the ordering of
a node-set.


On the other side, the XSLT 1.0 specs clearly defines
(http://www.w3.org/TR/xslt#misc-func):

"Function: string generate-id(node-set?) 

The generate-id function returns a string that uniquely identifies the
node in the argument node-set that is first in document order."

And in general, the definitions of all XPath and XSLT functions that
require a single node as argument repeat the above definition -- they
operate on "the node in the argument node-set that is first in document
order".

Cheers,
Dimitre Novatchev.

....

> Dimitre Novatchev schrieb:
> > Joerg Heinicke <joerg dot heinicke at gmx dot de> wrote:
> > 
> > 
> >>The [1] is implicit and not needed, because generate-id() on a 
> >>nodeset returns the id of the first element in this nodeset. I
> wrote 
> >>it for maybe better understanding.
> >>
> >><xsl:if test=". = preceding::bar[generate-id(ancestor::foo[1]) = 
> >>generate-id(current()/ancestor::foo[1])]">
> > 
> > 
> > This is one case where the established belief that 
> > 
> > generate-id(someXPathExpression) =
> generate-id(someXPathExpression[1])
> > 
> > is *not* true.
> > 
> > This is clearly not so, because "ancestor" is a reverse axis.
> > 
> > generate-id(ancestor::foo[1]) 
> > 
> > will be applied on the nearest ancesstor (the last in document
> order)
> > 
> > while
> > 
> > generate-id(ancestor::foo)
> > 
> > will be applied on the outermost ancestor (the first in document
> > order).
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Mother's Day is May 12th!
> http://shopping.yahoo.com


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com

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