Re: [xsl] position()

[Peter Flynn <peter at silmaril dot ie>]

At Tuesday, 3 April 2001, David wrote:

>I think the rant is misplaced. position() seems perfectly natural 
to me.

In any other environment than {SG|X}ML markup I would agree.

>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.

Counting nodes, yes. But the natural assumption -- to me, and doubtless
to many others -- is that position() should reflect elements: some other
function name should have been chosen for counting nodes.

>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?

Using position(), yes...it would be wrong in this case, of course,
because
your selection involves nesting. The logical solution would be that
position(section) would return 1, 2, 3...

I'm thinking of the much more common
occurrence of any sequence of siblings for which special action is 
required for a specifically numbered occurrence (or the last). If 
you look at any of the processing methods
used for SGML up until XSL, you will find this is the normal way 
of working.
*First() is also not easy if position() counts comments and white-space.

Counting comments is particularly destructive, because they are elided
in the output and should be transparent to the document structure: you
should be able to remove them between, say, paragraphs, and still have
position() return 3 when the current element is the third para in 
sequence.

I think this is the problem: XSLT does not treat the document structure,
it
treats the file structure at a much lower level. Which is just fine.
.but there
should be facilities for treating the document structure, one of 
which would
be returning n for the position within the current sequence of sibling 
*elements* (specifically). Which is also easy, but that is what position()
should return. My objection is simply to the hijacking of the name for
something which it does not imply.

>   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

Close. It still needs to co-operate with last() in order to detect the
last sibling in a sequence, though.

My argument is not with the concept, it's with the naming. The function
you give is actually what I use. My argument is that this is what ought
to have been called position, and some other name should be given
to the function which counts arbitrary random objects regardless of
type. There were clearly far too many computer scientists and not
enough real-world document processors around on the day this
function was named :-)

>   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.

I thought they were...in which case the example I saw looked wrong in
that it counted only the intervening comments, not the newline text 
nodes
between them and the surrounding elements. But that may just have been
my quick glance.








 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list