David,
Thank you for the quick reply.
I thought my testing showed that none of the elements were being evaluated
including xsl:xxx, but I was not able to reconstruct that when coming up with a smaller sample.
From my sample, ONLY extension elements were NOT being evaluated and being
copied literally into the variable.
I took a look at the spec and 11.4 does not mention anything about allowing / not allowing xsl expressions in a top level variable but it does say that the current context is the root node of the document.
The text of 11.4 is copied below.
I did a little digging into Xalan and there is a little different when processing
a global variable in that the result get copied into a global RTF. I tried to trace into the elemVariable code but could not find anything that seemed obvious. Is it possible that the extension NS table is not yet configured when global variables are processed causing them to be treated as literal elements ??
Thanks John G
XSLT 1.0 Spec http://www.w3.org/TR/xslt#top-level-variables 11.4 Top-level Variables and Parameters Both xsl:variable and xsl:param are allowed as top-level elements. A top-level variable-binding element declares a global variable that is visible everywhere. A top-level xsl:param element declares a parameter to the stylesheet; XSLT does not define the mechanism by which parameters are passed to the stylesheet. It is an error if a stylesheet contains more than one binding of a top-level variable with the same name and same import precedence. At the top-level, the expression or template specifying the variable value is evaluated with the same context as that used to process the root node of the source document: the current node is the root node of the source document and the current node list is a list containing just the root node of the source document. If the template or expression specifying the value of a global variable x references a global variable y, then the value for y must be computed before the value of x. It is an error if it is impossible to do this for all gl obal variable definitions; in other words, it is an error if the definitions are circular.
This example declares a global variable para-font-size, which it references in an attribute value template.
<xsl:variable name="para-font-size">12pt</xsl:variable>
<xsl:template match="para">
<fo:block font-size="{$para-font-size}">
<xsl:apply-templates/>
</fo:block>
</xsl:template>[EMAIL PROTECTED] wrote:
John G writes:
...I have a variable definition as follows: <xsl:variable name="extTest"> <myExt:doSomething>Text Here</myExt:doSomething> </xsl:variable> When the variable is declared in a template, the variable value is exactly what I expected, $extTest = "Something Else"; When the variable is defined in the global space, the value of extText is a copy of the literal text $extTest =...
(Working from memory on this answer) I believe the content of a top-level xsl:variable should behave the same as the content of xsl:template, except for the context. See the section on global variables for details on what the context node and node list should be when a global variable is evaluated.
Also check the extensibility material in the spec regarding extension "instructions" (which are content of a template or global xsl:variable) as opposed to extension top-level elements (which act like declarations to a processor that understands them. .................David Marston
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
