Bug #3981


No error when the value of a static parameter is supplied at execution time

Added by Michael Kay almost 5 years ago. Updated almost 5 years ago.

s9api API
Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


When a stylesheet declares a static parameter, Saxon allows a value to be supplied for the parameter at execution time. This means that the compile-time and run-time values of the parameter may differ, which is contrary to the intent of the spec, and has potential to cause chaos if the optimizer replaces references to the parameter with its compile-time value.

Demonstrated by a new unit test TestStaticAttr/testStaticAtt6

Actions #1

Updated by Michael Kay almost 5 years ago

I've added code to XsltTransformer.setParameter() and Xslt30Transformer.setStylesheetParameters() to check that the parameter being set isn't declared as static.

This doesn't quite feel right. Firstly, these method have until now ignored anything the stylesheet says about the parameter; they just capture the value for future use. Secondly, we're doing the check at the wrong level; it can be bypassed by setting the parameter value directly on the Controller. However, the parameters are passed to the Controller using Controller.initializeController(), and this explicitly requires the parameter set to contain values for both static and dynamic parameters.

I think a better way forward is that the parameters passed to Controller.initializeController() should NOT include the static parameters (which are already available in the PreparedStylesheet)

I've now changed it as follows:

  • the XsltTransformer and Xslt30Transformer no longer merge the static parameters into the globalParameters variable.

  • Controller.initializeController no longer expects the supplied parameters to include parameters that were statically supplied. Indeed, it now checks that the supplied parameters (a) don't include any that were declared with static="yes", and (b) don't include any that were already supplied as parameters to the XsltCompiler.

This change is moderately disruptive (I had to make a number of corrections to test cases, to the XSLT 3.0 test driver, and to one or two XSLT 3.0 tests to make it work). I'm therefore going to make no change for Saxon 9.8.

Actions #2

Updated by Michael Kay almost 5 years ago

  • Status changed from New to Resolved
  • Applies to branch 9.9 added
  • Fix Committed on Branch 9.9 added

I needed to make some further changes for command line parameters to work - this underlines that this change might be a little troublesome. But I still think it's worth making (on 9.9 only) because the consequences of supplying different parameter values at different times are pretty horrible.

I implemented a further change: during the optimization phase, references to static parameters (in non-static expressions) are now inlined (so the variable reference is replaced by the actual statically-supplied value) - which paves the way to further optimizations by folding constant expressions, deleting conditionals that will always be false, etc.

Actions #3

Updated by O'Neil Delpratt almost 5 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release added

Bug fix applied to the Saxon maintenance release.

Please register to edit this issue

Also available in: Atom PDF