[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] String conversion problem when string is large


Subject: Re: [xsl] String conversion problem when string is large
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 21 Mar 2012 17:52:11 +0000

Just to confirm, do I read correctly that

<xsl:param name="string" as="xs:string">string</xsl:param>

will be passed and processed as a string rather than a tree?
Yes, that's correct. Technically a document is constructed and then atomized to create the string, but it doesn't require a great deal of brain-power to short-circuit this.

Actually with Saxon this will also often happen with:

<xsl:param name="s">string</xsl:param>

With xsl:param and xsl:variable Saxon attempts to analyze the usage of the variable. If all uses of the variable are in atomizing contexts, then Saxon rewrites it as a string to avoid the overhead of creating the tree. But there's no attempt to do this in the case of xsl:with-param, because it requires global analysis, prevention of cycles when handling recursion, etc.

I have been working in the belief (also in analogous cases) that it does, but as long as we're on the topic I wonder if you can speak to it.


Plus, I am wondering whether I can know that this will happen in any XSLT 2.0 processor, not only Saxon.
Since most XSLT 2.0 processors are closed source, we have no way of knowing.

The main reason I need this settled in my mind is that, as you say, this comes up very commonly; and one of the most mystifying pieces of advice we give to beginners is to prefer using @select, when possible, to a literal value in a parameter or variable assignment, even though the latter is legal and it works, under one definition of "work". If the workaround is really this easy (and if it even suggests the nature of the underlying problem, as this appears to), that might help.


In other words, if

<xsl:param name="string" as="xs:string">string</xsl:param>

is long for

<xsl:param name="string" select="'string'"/>
Well, there are other benefits in declaring the type. These two constructs aren't equivalent, because in the first case the processor knows that the value will always be a string, whereas in the second it's only a string in the case where it's defaulted.


we should see similarly that

<xsl:param name="string">string</xsl:param>

is another way of saying

<xsl:param name="string" as="document-node()">
<xsl:document>string</xsl:document>
</xsl:param>

Is this correct?
Yes, that's true.

Michael Kay
Saxonica


Current Thread
Keywords