This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: the nearest ancestor with the attribute
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] the nearest ancestor with the attribute
- From: David Carlisle <davidc at nag dot co dot uk>
- Date: Thu, 18 Jan 2001 11:22:42 GMT
- References: <9B66BBD37D5DD411B8CE00508B69700F4F0022@pborolocal.rnib.org.uk>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> Is that the generality then Mike, given a 'confusing' mix
> of axis, it comes back unordered,
No it's simpler than that. it _always_ comes back as a set.
(and sets are by definition unordered).
select="ancestor::*"
produces the _set_ of ancestors, it isn't ordered at all.
<xsl:variable name="x" select="ancestor::*"/>
puts that variable in a set.
<xsl:variable name="x" select="$x[1]"/>
the operation of applying the predicate [1] (ie [position()=1]takes the
first node in document order. But that is a feature of the operation not
of the node set $x.
Note this is not the same as applying a predicate within a step, which
is the only place the axis order has any effect
<xsl:variable name="y" select="ancestor::*[1]"/>
selects the parent, unlike the $x[1] which selects the document element
(ie the outer most ancestor)
> operations on an unordered set
"unordered set" is a tautology. "set" _means_ unordered collection.
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list