Saxon

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.

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

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.

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.

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.

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.

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.