Re: Result Tree Fragments & Variables

[David Carlisle <davidc at nag dot co dot uk>]

> <!-- this is why I thought variables could be bound to node-sets -->

they can,
<xsl:variable name="x" select="/xxx/yyy"/>
binds x to the node set of nodes rom the input document that are
selected by that xpath expression. But note this is an empty
xsl:variable using the select attribute.


> <!-- But aren't "permitted operations" standard, unless one means by
> standard most currently in use by stylesheet writers? -->

they are standard on node sets.
But you can't use any node set operations on result tree fragments
except
copying the whole thing to the result (or another result tree fragment)
or
converting it to a string by just taking all the character data.

In otherwords you can not query into or deconstruct the tree in any way,
you can just use it as an opaque lump of stuff.

> intrepret this to mean that the absence/presence of the select attribute
>  is decisive here in determining the data-type which will result from the
> binding. -->

yes exactly. I described it as having content or being empty, but
equivalently you could say having or not having the select attribute.
if xsl:variable is empty you have to have a select attribute (except for
the degenerate case of an empty rtf) if it is non empty you must not have it.



> Is it the case that
> 	<xsl:variable select="*"/>
> will bind the variable to a node set?

yes it will but it is essentially a subset of the input tree.

what you can't do is bind a variable to a constructed node set (such as
the result of an xsl:sort) because in order to make the construction
you have to place the stuff in the body of an xsl:variable, then
what you get back isn't a node set its an rtf (see my example in earlier
post). 

David


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