Marty,
It's all in the distinction between a node set and a result tree fragment.
In XSLT 1.0, by design, the processor builds a result tree, but does not
take either that result tree or pieces of it as input trees for further
processing. It can also create pieces of result tree just to have around,
for example for easy reuse -- these are called "result tree fragments"
(sometimes you'll see it abbreviated to RTF on this list, so watch out). Of
course there's nothing that actually forces you, if you create an RTF, to
place it in the result tree, and except for the fact that the spec says
it's not allowed to process them like node sets, they're really exactly
like node sets in how they're constructed.
So....
At 08:00 PM 2/26/2003, you wrote:
I was trying to use xalan:node-set() one day, with errors, and on a whim
just went ahead and did
<xsl:for-each select="$foo//*[@bar]">
and to my suprise it worked.
$foo was an honest node set at that point.
If you say
<xsl:variable name="foo" select="//baz"/>
$foo will be a node set. If you say, however,
<xsl:variable name="foo">
<xsl:copy-of select="//baz"/>
</xsl:variable>
it's not a node set, it's an RTF. In which case, you can't say
$foo//*[@bar] or use $foo in XPath expressions much at all (you can use it
as a string but that's it). This is why many or most processors have the
node-set() extension, to turn it back so it can be traversed -- a very
handy thing to be able to do.
Is there any difference bewteen "x:nodeset($foo)/@bar" and "$foo/@bar"
If $foo is a node set, no. If it is an RTF, yes.
and what are the costs of using this trick?
It's not really a trick, it's the way the language is supposed to work.
This is part of the reason you'll find experienced XSLTers using the select
attribute on variable and parameter assignments as much as possible, so we
get honest node sets instead of RTFs, which, though useful, are only half
the deal.
PS:
i still occasionally get the "Cannot convert #STRING to a NodeList" error.
Not sure why.
RTFs can be turned into strings, but not otherwise processed except to be
copied to the result tree. This error could happen because you're trying to
traverse an RTF -- i.e. the reverse of what you noticed above, fixed by
passing the RTF to a function that makes a node set out of it.
This distinction between RTFs and node sets will be disappearing in XSLT
2.0. They'll always be node sets and you won't need the extension function.
Cheers,
Wendell
___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
"Thus I make my own use of the telegraph, without consulting
the directors, like the sparrows, which I perceive use it
extensively for a perch." -- Thoreau
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list