Cart
[Home] [By Thread] [By Date] [Recent Entries]
A follow up after some testing and trial and error. The proposed
solution works partially, thanks again for this pointer, but we get
(indeed Michael, you were right) strange results for any <xsl:param>
value that is not a quoted literal. So:
A. <xsl:param name="somenameA" select=" 'literal-string-A' " /> B. <xsl:param name="somenameB" >literal-string-B</xsl:param> (A) correctly returns "literal-string-A" (incl. quotes) (B) (in?) correctly returns "net.sf.saxon.instruct.DocumentInstr@d1a34a" (without quotes) We have tried evaluateAsString (Expression and ComputedExpression classes) and some other things, basically all requiring an XPathContext, and setting context to null did not help, although the docs hint as if it should. My guess is that the XSLT processor sees the content of (B) as a node set, containing one node, namely a text node. I wonder, is there a way of doing something like: rootContext = compiledStylesheet.getRootContext();
if(ParamB.canEvaluateToString())
return ParamB.evaluateToString(rootContext);
else
return null;So: I would like to know a way to get the normalized string representation, unless the xsl:param is a node set (other than a single text node) or an xpath instruction. Any help on this follow up is greatly appreciated. Cheers, Abel andrew welch wrote:
|
