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