Saxon

In looking for test cases I found that we actually have a partial implementation of the IXSL function library that invokes Nashorn to execute Javascript when running Saxon under Java. It's a very partial implementation and can only handle simple cases, because the Javascript<->XPath type conversion hasn't been thought through - it only works for simple cases like computing a string or integer. Making this useful would require a lot more development and testing and I'm not going to attempt that right now.

I think that function-available() should therefore return false for these functions unless the target environment is JS. If the compilation target is JS but execution takes place on the Java platform, execution of the function should fail cleanly.

I've been adding some tests for function-available in jstests/IxslExtensionTest; will come back to element-available() later.

Looking back at comment #1, I'm not sure why I excluded package-related elements like xsl:accept and xsl:override from the Saxon-JS list. These elements are not currently handled by the new XX compiler, but they should work perfectly well when compiling a stylesheet for Saxon-JS using the Saxon-EE compiler.

For the XSLT namespace, I've changed it so all XSLT elements are available regardless of target edition (subject to the special rules for xsl:evaluate, which can be disabled).

For the IXSL namespace, my first instinct is that EnterpriseConfiguration.declareBuiltInExtensionElementNamespaces() shouldn't add the IXSL namespace unless target="JS". But that then raises the question, why is this a configuration property in the first place? Shouldn't be allowed to vary from one XSLT compilation to another?

As a closely related question, we need to ask how the XSLT compiler should behave if an ixsl:schedule-action instruction is present but target="JS" isn't specified. If we change things so that ixsl is no longer a built-in extension element namespace, then the likely outcome is that the instruction will be treated as a literal result element, which means there will no compile-time error, just unexpected behaviour at run-time.