RE: [xsl] position()

Subject: RE: [xsl] position()
From: DPawson@xxxxxxxxxxx
Date: Tue, 3 Apr 2001 12:52:43 +0100
is there an echo on the list again?

Either that or Peter and David ..... no, perhaps not ;-)

Regards DaveP

>    <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
>  XSL-List info and archive:

 XSL-List info and archive:

Current Thread