Bug #3535


initial-function parameters are not type-checked

Added by John Lumley over 6 years ago. Updated almost 4 years ago.

Start date:
Due date:
% Done:


Estimated time:
Applies to JS Branch:
1.0, Trunk
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Contact person:
Additional contact persons:


Stylesheeets can be invoked through execution of an initial stylesheet function using the initialFunction and functionParams options of SaxonJS.transform().

Internally the transform finds the function declaration, sets the given parameters into the local variable slot frame and then executes the sequence constructor body of the function. In the process the types of the presented parameter values are not checked. Thus for example executing:

<xsl:function name="f:bar>
  <xsl:param name="a" as="xs:integer"/>
<xsl:sequence select="2 * $a"/>

with $a bound to JavaScript "foo" or xs:string("foo") will result in a thrown (non XError) error as the rhs.toNumber() function does not exist for xs:string when the integer * integer calculation is performed. Equally well valid promotion or casting is not carried out, so for example "" passed to a parameter typed as xs:anyURI would not be converted and subsequent code may fail.

In the case of parameters passed through initialMode or initialTemplate invocations, the parameter binding instructions contain compiler-generated JavaScript acceptor code so they are type-checked. But for stylesheet functions called internally, any argument type checking is performed in the call, not the function itself.

The arguments in the function declaration do have type annotations in an @as attribute, but this is not used at run time in SaxonJS.

To correct this would require some generic type-checking mechanism in SaxonJS invoked in the initial-function section of transform(). The XPath compiler contains code that may be adaptable but which is currently targetted to generating potential type-check/conversion code rather than actually carrying out the check or conversion. It would require module separation to enable it to be used independently of dynamic XPath evaluation, which is designed to be a separately loadable module.

An alternative might be for the EE compiler to add Javascript acceptor/conversion code attributes to parameters of initial functions with public or final visibility and pick these up and run them during parameter slot value binding.

Please register to edit this issue

Also available in: Atom PDF Tracking page