Saxon

The same problem applies to function-available() and element-available() - we don't really know what will be available until the code is imported into the execution environment.

Note that given the current API, we don't actually know while compiling a stylesheet (package), that it is going to be exported.

On the saxon-dev branch I have made some changes so system-property avoids early evaluation of certain properties, like is-schema-aware. But I'm not sure this is the final solution. I think that when we're compiling a stylesheet for export, we need to be told something about the target execution environment. For example, we want static errors if there are calls on fn:sort() and the target environment is one that doesn't support higher-order functions; similarly, use of system-property() and function-available() within static expressions should give a result that reflects the capabilities of the target environment.

I think the right way forward for this is probably to introduce some kind of setting on the XsltCompiler that says what the target platform is. So if you're under EE, you might be compiling for execution under HE, perhaps in future for execution in a Javascript environment, and we should require the user the opportunity to say that (or perhaps to explicitly say that the target platform is not known / generic). Functions like system-property and function-available will then be evaluated with respect to the target platform if known, or evaluation will be deferred to run-time if the target platform is unknown.

I have implemented this as follows:

(a) an option -target is available on the Transform command line. The value is the target edition for executing the stylesheet, e.g. EE, PE, HE, JS.

(b) the same option is available in s9api as XsltCompiler.setTargetEdition(), or if required as an option on the CompilerInfo.

(c) the option affects the results of system-property(), element-available(), and function-available() when executed at compile time (either in ordinary code, or in a use-when expression). For example, if the target edition is HE, then element-available('xsl:merge') returns false.

(d) the option also affects the contents of the export file. Currently this is only true for target:JS, which is mandatory if the stylesheet is to be executed under Saxon-JS. The option causes some constructs, for example item type tests, to be compiled into fragments of Javascript code which are included in the export file.

There is scope for further use of this option in future, either (a) for early diagnostics if the stylesheet uses constructs that are not available on the target platform, or (b) for generating code in a different way, e.g. fallback code for streaming.