Subject: Re: [xsl] position() From: Peter Flynn <peter@xxxxxxxxxxx> Date: Tue, 3 Apr 2001 10:29:00 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] position(), David Carlisle | Thread | Re: [xsl] position(), David Carlisle |
Re: [xsl] position(), David Carlisle | Date | RE: [xsl] Xalan question: XML to S, Nick Vincent |
Month |