S Woodside wrote:
I'm beginning to think that XSLT is a bit like magic. If you think the
right way, and use the right magic incantation, it works like a charm.
If you don't, no cigar.
I have this top-level param to grab a param from http:
<xsl:param name="StartPointStr">.</xsl:param>
The param StartPointStr is an Xpath string.
...unless it wasn't supplied, in which case it is a result tree fragment
consisting of a root node with a text node child, the text node encapsulating
a period character. You probably intended for it to be just a string:
<xsl:param name="StartPointStr" select="'.'"/>
Next I have this (which works) (1)
<xsl:param name="StartNode" select="dyn:evaluate($StartPointStr)"/>
Compare to this (which doesn't work): (2)
<xsl:param name="StartNode">
<xsl:attribute name="select">
<xsl:value-of select="dyn:evaluate($StartPointStr)"/>
</xsl:attribute>
</xsl:param>
xsl:attribute adds an attribute to an element node that has been created
*in the result tree*, not in the stylesheet tree.
If you had put a literal result element in the stylesheet, it would
have been copied through to the result tree, along with the generated
attribute added to it.
LibXSLT doesn't complain
In the section of the spec that describes xsl:attribute, it says "Adding an
attribute to a node that is not an element [is an error]; implementations may
either signal the error or ignore the attribute." LibXSLT is free to ignore
it.
Mike
--
Mike J. Brown | http://skew.org/~mike/resume/
Denver, CO, USA | http://skew.org/xml/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list