Bug #5556
closedelement-available('xsl:import-schema') returns true for Saxon-HE, and when compiling for SaxonJS
100%
Description
Saxon-HE is non-schema-aware, so I'd expect element-available('xsl:import-schema')
to return false, however it returns true.
Updated by Debbie Lockett almost 2 years ago
I discovered this bug investigating the failure of XSLT 3.0 test suite test catalog-006b in SaxonJS. The test fails there because element-available('xsl:import-schema')
correctly returns false for non-schema-aware SaxonJS; but the tests catalog-006 and catalog-006b expect that "all XSLT element names in non-error stylesheets satisfy element-available()". So these test should actually have a dependency on the "schema_aware" feature.
Updated by Debbie Lockett almost 2 years ago
- Subject changed from element-available('xsl:import-schema') returns true for Saxon-HE to element-available('xsl:import-schema') returns true for Saxon-HE, and when compiling for SaxonJS
When exporting to SEF for use with SaxonJS (using -target:JS
), the compile-time evaluation of element-available('xsl:import-schema')
also returns true. Though the SaxonJS documentation (https://www.saxonica.com/saxon-js/documentation2/index.html#!starting/export/compiling-using-XJ) says that:
compile-time evaluation of functions such as system-property(), function-available(), element-available() considers the target environment, not the compiler environment.
Updated by Debbie Lockett almost 2 years ago
Moreover, when compiling for SaxonJS, if a stylesheet uses xsl:import-schema, we should throw a XTSE1650 error at compile time. (Currently when exporting to SEF with Saxon-EE 10 and 11, there is no error, such a stylesheet seems to be exported OK; but the SEF then contains a "schema" reference, which is ignored by SaxonJS, and so can lead to unexpected results.)
Updated by Michael Kay over 1 year ago
I think that the result of element-available('xsl:import-schema')
should be aligned with the result of system-property('xsl:is-schema-aware')
.
This is currently based on calling boolean schemaAware = rsc.getPackageData().isSchemaAware();
. The value of schemaAware
in the StylesheetPackage
appears to depend on the value of schemaAware
in the Compilation
. The methods PrincipalStylesheetModule.checkForSchemaAwareness()
and UseWhenFilter.startElement() both force this to true if an
xsl:import-schema` declaration is encountered. There's also a reference in the code to bug #3105, which is in the same general area.
Updated by Michael Kay over 1 year ago
The Compilation
, knows (via the CompilerInfo
) what the targetEdition
is. Therefore, if the targetEdition
is not EE, we can prevent schemaAware
being set to true, even if an xsl:import-schema
declaration is encountered. I'll do some experiments.
Updated by Michael Kay over 1 year ago
First, I've changed element-available('xsl:import-schema')
to return false if the static context package data has schema-aware=false.
I'm now attempting to show that if the compilation hasn't been explicitly set to schema-aware or not, then it depends on the presence of an xsl:import-schema declaration. This is currently failing for a reason that seems unrelated.
There's a basic contradiction here. During static preprocessing (when we evaluate use-when attributes), we can't look ahead to see whether there is an xsl:import-schema declaration before deciding what element-available('xsl:import-schema')
should return.
Proposed resolution: element-available('xsl:import-schema')
returns true if the compilation is "potentially schema aware". It is potentially schema aware if the following conditions are true:
(a) We're running Saxon-EE with a license.
(b) We haven't called setSchemaAware(false).
(c) We haven't set the (export) target to a non-schema-aware Saxon edition.
If the compilation is potentially schema aware then
(a) `element-available('xsl:import-schema')` returns true (otherwise false)
(b) `system-property('xsl:is-schema-aware')` returns true (otherwise false)
(c) xsl:import-schema is allowed (otherwise it throws an error)
A compilation is "actually schema aware" if it is potentially schema aware and either
(a) We have called setSchemaAware(true), or
(b) The stylesheet uses xsl:import-schema
If a compilation is "actually schema aware" then at runtime the transformation allows typed nodes to be supplied as input, otherwise it doesn't.
Updated by Michael Kay over 1 year ago
I decided this was all too disruptive.
I'm now simply changing element-available('xsl:import-schema')
so it returns true iff (a) the "current" config is a licensed EE configuration, and (b) the target configuration is EE (by default, the target configuration is the same as the current configuration). Everything else remains the same, except I shall try and document it better.
Note in particular that setting XsltCompiler.setSchemaAware(false)
does not prevent the use of xsl:import-schema
; rather, using xsl:import-schema
has the effect of forcing the compilation to be schema aware regardless.
Updated by Michael Kay over 1 year ago
While reviewing this, I've changed system-property('supports-serialization')
to report true regardless of the target environment. Currently it reports false if the target is JS.
Updated by Michael Kay over 1 year ago
- Status changed from In Progress to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Fix Committed on Branch 11, trunk added
- Platforms .NET, Java added
Changed code of element-available(), plus documentation.
Updated by Debbie Lockett over 1 year ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 11.4 added
Bug fix applied in the Saxon 11.4 maintenance release.
Please register to edit this issue