Project

Profile

Help

Bug #5556

closed

element-available('xsl:import-schema') returns true for Saxon-HE, and when compiling for SaxonJS

Added by Debbie Lockett 2 months ago. Updated 11 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2022-06-09
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 11, trunk
Fix Committed on Branch:
11, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

Description

Saxon-HE is non-schema-aware, so I'd expect element-available('xsl:import-schema') to return false, however it returns true.

Actions #1

Updated by Debbie Lockett 2 months 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.

Actions #2

Updated by Debbie Lockett 2 months 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.

Actions #3

Updated by Debbie Lockett 2 months 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.)

Actions #4

Updated by Michael Kay 25 days 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.

Actions #5

Updated by Michael Kay 24 days 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.

Actions #6

Updated by Michael Kay 24 days 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.

Actions #7

Updated by Michael Kay 22 days ago

  • Status changed from New to In Progress
Actions #8

Updated by Michael Kay 21 days 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.

Actions #9

Updated by Michael Kay 21 days 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.

Actions #10

Updated by Michael Kay 21 days 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.

Actions #11

Updated by Debbie Lockett 11 days 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

Also available in: Atom PDF