Project

Profile

Help

Bug #3535

initial-function parameters are not type-checked

Added by John Lumley over 2 years ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
API
Sprint/Milestone:
-
Start date:
2017-11-18
Due date:
% Done:

0%

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

Description

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 "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(). 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.

History

#1 Updated by Debbie Lockett over 2 years ago

For stylesheet parameters, at compile time we generate jsAcceptor and jsCardCheck properties/functions. We could do the same for function parameters (and initial template parameters) - perhaps only if they are declared explicitly as public.

#2 Updated by Debbie Lockett about 2 years ago

  • Description updated (diff)

#3 Updated by John Lumley about 2 months ago

Retaining this for now as it can effect users of Saxon-JS2

#4 Updated by Michael Kay about 2 months ago

  • Status changed from New to Closed
  • Fixed in JS Release set to Saxon-JS 2.0

I've written a series of API tests async-trans-018a...i to test initialFunction invocation using parameters with and without conversion, including error cases. No problems found, so I'm closing the bug.

#5 Updated by Debbie Lockett about 2 months ago

  • Category set to API

Please register to edit this issue

Also available in: Atom PDF Tracking page