Bug #4238
closed
In Saxon-EE, element-available() always returns true for IXSL extension elements
Category:
Saxon extensions
Applies to branch:
9.8, 9.9, trunk
Fix Committed on Branch:
10, 9.9
Fixed in Maintenance Release:
Description
The result of element-available()
should depend on the target edition. e.g. element-available('ixsl:schedule-action')
should return true when exporting for Saxon-JS, but not otherwise.
Note that ElementAvailable.isElementAvailable()
takes the target edition into account for elements in the XSLT namespace, but apparently not otherwise. (But this should also be reviewed - the list of XSLT elements allowed by isSaxonJSElement
doesn't look right.)
If a stylesheet containing an IXSLT extension element is run in Saxon-EE, then this results in a run-time error ("ixsl:schedule-action is available only in Saxon-JS", with no error code), rather than a compile-time error.
- Fix Committed on Branch 9.9, trunk added
On the development branch, I have updated the list of XSLT elements available in Saxon-JS to include all except accept, expose, import-schema, override, package, and use-package.
I noticed that the code is not handling an EQName of the form Q{uri}local
in the case where the URI contains a colon. Fixed this on 9.9 and trunk; added XSLT30 test case function-0303.
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.
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Fix Committed on Branch 10 added
- Fix Committed on Branch deleted (
trunk)
Decided to special-case this within element-available(). The code for element-available() now returns false if the URI is the IXSL namespace and the target edition is not "JS".
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.1 added
Bug fix committed in the Saxon 10.1 maintenance release.
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 10.2, 9.9.1.8 added
- Fixed in Maintenance Release deleted (
10.1)
Bug fix applied on the Saxon 9.9.1.8 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF