Saxon » SaxonJS

Bug #3535

Updated by Debbie Lockett over 6 years ago

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

 @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 `"http://saxon.sf.net/"` 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()`. @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.  
  

Back