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 <http://www.w3.org/TR/xslt#dt-expression>;
this expression is evaluated and the resulting object is converted to a
string as if by a call to the *string
<http://www.w3.org/TR/xpath#function-string>*function." [3], where "A
node-set is converted to a string by returning the string-value
<http://www.w3.org/TR/xpath#dt-string-value> of the node in the node-set
that is first in document order
<http://www.w3.org/TR/xpath#dt-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!
Francis.
[1] http://www.w3.org/Style/XSL/
[2] http://zvon.org/o_html/group_xsl.html
[3] http://www.w3.org/TR/xslt#value-of
[4] http://www.w3.org/TR/xpath#function-string
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list