This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: position()
- To: xsl-list at lists dot mulberrytech dot com
- Subject: RE: [xsl] position()
- From: Peter Flynn <peter at silmaril dot ie>
- Date: Tue, 3 Apr 2001 00:03:19 +0100
- Organization: Silmaril Consultants
- References: <191E23677373D411BFB900D0B7A7BA28025C40@mail.vbninternal.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
On Mon, 02 Apr 2001, Richard Mitchell wrote:
> Well yes, but I would have thought that xsl like
>
> <xsl:template match="object">
> <xsl:value-of select="concat(position(),' ',@name)"/>
> </xsl:template>
>
> on input of
>
> <objects>
> <!-- hello -->
> <object name="first"/>
> <object name="second"/>
> <!-- hello -->
> <object name="third"/>
> <object name="fourth"/>
> </objects>
>
> Would produce
>
> 1 first
> 2 second
> 3 third
> 4 fourth
<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.
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().
I'm a little surprised that the newlines between TAGC and STAGO
are not counted as text nodes :-)
</rant>
///Peter
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list