No error when the value of a static parameter is supplied at execution time
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
#1 Updated by Michael Kay about 3 years ago
I've added code to
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
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.
#2 Updated by Michael Kay about 3 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.
Please register to edit this issue