This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: position()
<rant>
Yes, so it should. The decision to make it behave otherwise was
IMHO entirely bogus, I'm afraid. Especially in view of the fact
that SGML processing languages all implement their positional
function wrt the referenced element type in its location within
its parent, as one would expect. But it's not something that will
ever change.
I think the rant is misplaced. position() seems perfectly natural to me.
what you are asking for sounds more like xsl:number. In any language
that has a list concept having access to the length of the list (last())
and position in the list seems quite common. That is what position() does.
You say position() should have been defined to give the sibling element
position. So in
<xsl:for-each select="section/title">
section <xsl:value-of select="position()"> <xsl:value-of select=".">
</xsl:for-each>
You think that it would be more natural for every section to be
labeled "1" as every title (in a document you'll just have to imagine)
is the first child of its parent?
Until someone can produce a function that behaves in a normal
manner (ie as above), it needs to be remembered (and FAQ'd?)
that position() means node-position(), not element-position().
That function is count(preceding-sibing::*)+1
I'm a little surprised that the newlines between TAGC and STAGO
are not counted as text nodes :-)
</rant>
As I mentioned before, they are.
///Peter
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