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 >  > 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  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) = > >>generate-id(current()/ancestor::foo)]"> > > > > > > This is one case where the established belief that > > > > generate-id(someXPathExpression) = > generate-id(someXPathExpression) > > > > is *not* true. > > > > This is clearly not so, because "ancestor" is a reverse axis. > > > > generate-id(ancestor::foo) > > > > 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format