Re: [xsl] preceding-sibling inside for-each appears to fail

Subject: Re: [xsl] preceding-sibling inside for-each appears to fail
From: Francis Norton <francis@xxxxxxxxxxx>
Date: Mon, 10 Feb 2003 06:32:31 +0000
Hi Ted,

Ted Stresen-Reuter wrote:

Wow... that did the trick, but I'm not sure I fully understand the positional predicate.

Well, your experiment was bang on target. If you want to know more about it I'd suggest a look at the XSLT and XPath specifications [1], a good book such as Michael Kay's "Porfessional XSLT", and / or a session with the interactive Zvon XPath labs [2]

Because this is the kind of person I am, I also tried running it with "-1" to see if, in fact, you could "reverse" the direction (and effectively reproduce the results of following-sibling). The results show that you can not:

Good attitude for learning software. :)

What I'm having a little difficulty understanding is exactly why preceding-sibling, in this example, requires a positional predicate while following-sibling doesn't.

I should have explained that with xsl:value-of "The required |select| attribute is an expression <>; this expression is evaluated and the resulting object is converted to a string as if by a call to the *string <>*function." [3], where "A node-set is converted to a string by returning the string-value <> of the node in the node-set that is first in document order <>." [4]. In other words, the expression is returning a node-set, much like a SQL statement returns a result table, but xsl:value-of is only reporting the first member of the node-set in document order. So it would be perfectly correct to put a positional predicate on the following-sibling expression, just redundant in this case.

Also, I thought that the node-set returned by the select attribute in the for-each element was complete. In other words, I thought that the select attribute function a little like a select statement in SQL and that the contents of the for-each element acted on the results of the select "statement", but the behavior demonstrated by this code implies that the resulting node-set is built during the loop and NOT as some internal mechanism fetching a "record set" (in MS terminology).

Your first intuition was correct, it is more like a SQL statement. But it's running relative to the current node, and in the first two iterations the current node doesn't have two preceding siblings.

I think some of my difficulty understanding how this works stems from my background with other programming languages where the result of a function is returned at the end, and not during execution.

Thank you very much for your prompt (and accurate) reply. I am now able to proceed with my project (this had me stuck for a week).

Glad to help!



XSL-List info and archive:

Current Thread