Bug #4238


In Saxon-EE, element-available() always returns true for IXSL extension elements

Added by Debbie Lockett about 3 years ago. Updated almost 2 years ago.

Saxon extensions
Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
9.8, 9.9, trunk
Fix Committed on Branch:
10, 9.9
Fixed in Maintenance Release:


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.

Actions #1

Updated by Michael Kay about 3 years ago

  • 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.

Actions #2

Updated by Michael Kay about 3 years ago

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.

Actions #3

Updated by Michael Kay almost 3 years ago

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.

Actions #4

Updated by Michael Kay over 2 years ago

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.

Actions #5

Updated by Michael Kay over 2 years ago

  • 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".

Actions #6

Updated by O'Neil Delpratt about 2 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.1 added

Bug fix committed in the Saxon 10.1 maintenance release.

Actions #7

Updated by O'Neil Delpratt almost 2 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 10.2, added
  • Fixed in Maintenance Release deleted (10.1)

Bug fix applied on the Saxon maintenance release.

Please register to edit this issue

Also available in: Atom PDF