Saxon

I am wondering whether it would be simpler and safer to have a more coarse restriction: "A stylesheet containing node-valued static variables cannot be exported".

Or perhaps we should only allow document nodes. Even then, some of the properties are lost, such as base URI, document URI, and "$x is $y" where $x and $y are two exported document nodes.

Another approach would be export not the value of the static variable, but the expression for constructing its value, and to re-evaluate this expression when the SEF file is reloaded. But this doesn't help in the case of node-valued static parameters.

It's not just nodes that cause problems.

We have code for exporting "external Java objects", but make no attempt at corresponding import code. It's basically impossible (except perhaps by Java serialization) so we should just disallow it. I've modified the code so this is an error at export time, rather than causing an error at import time.

For nodes, I feel the solution might be to build up a list of distinct trees that are referenced from the SEF, with identifiers and base URIs / document URIs, and output these all at the end (perhaps in CDATA to avoid namespace pollution); the value itself should then be output in the form <node tree="823" path="(path-to-node)" kind="(node kind)"/>. This would allow retention of relationships within a tree.

This has come up in a user-submitted bug report, bug #4117.

In that case the scenario is fairly simple: a single global variable whose value is a document node. We can handle that case by generating code to reconstruct the document, for example by applying parse-xml() to a serialization.

The complication arises when we have global variable referring to multiple nodes within such a document. Do we attempt to generate one variable containing the document as a whole, and further variables referring to selected nodes within it?

I think an easier approach is probably to export the variables as if they were not static. The static processing has already been done before the export happens; it should be possible to simply re-evaluate the variables at execution time, as if they were not static at all. As already stated, this doesn't work for static parameters. But perhaps we impose a restriction for that case.

I decided to look more closely at how we export stylesheets containing static parameters. For example test static-002 has source

<xsl:param name="static-param" static="yes" select="'success'"/>
<xsl:param name="alt-param" static="yes" select="upper-case($static-param)"/>

and compiles to:

<co id='0' binds=''>
  <globalParam name='Q{}static-param' type='item()*' line='6' module='file:/Users/...../attr/static/static-002.xsl' visibility='PRIVATE'>
   <str val='success'/>
  </globalParam>
 </co>
 <co id='1' binds=''>
  <globalParam name='Q{}alt-param' type='item()*' line='8' module='file:/Users/...../attr/static/static-002.xsl' visibility='PRIVATE'>
   <str val='SUCCESS'/>
  </globalParam>
 </co>

So (a) there seems to be no indication that the parameter was originally declared static, which means a value can be supplied at run-time, (b) however, the default value for $alt-param will not be affected by any run-time value supplied for $static-param. I think it would make more sense if the compile-time value of a static param were "frozen" to prevent a different value being supplied at run time. This is most easily achieved by exporting it as a variable rather than a param.

(This doesn't solve the original problem, but it removes one of the complications.)

I have made this change (9.9 and trunk) and have also added flags="s" for static variables/parameters, essentially for future use if needed.