Bug #3105
closedsystem-property('xsl:is-schema-aware') called within use-when always returns false
100%
Description
Raised here: https://saxonica.plan.io/boards/3/topics/6642?pn=1
It seems that system-property('xsl:is-schema-aware') always returns false when called within a static expression.
This happens because static expressions are evaluated with no schema information in the static context, which means that for practical purposes the static expressions themselves are not schema aware. But the intent of using this call is to discover whether the stylesheet as a whole is schema-aware. In fact, in the language of the spec, it is to discover whether the "processor" is schema-aware.
A problem with this is that Saxon, if the user hasn't said anything explicitly, switches schema-awareness on when it encounters an xsl:import-schema declaration - and (a) it may already have processed static expressions before it encounters this, and (b) worse still, the xsl:import-schema may itself be controlled by a use-when="sysProp(schema-aware)" attribute.
Updated by Michael Kay almost 8 years ago
It's a tricky one, because
(a) We don't want to default to being "schema-aware" just because the user is running EE with a license, because unless they've written the stylesheet code to benefit from schema-awareness, this gives costs and no benefits (when running schema-aware with no schema, we have no idea what the static type of @someAttr is, for example, whereas when running schema-unaware, we know it will be xs:untypedAtomic).
(b) If we encounter an xsl:import-schema declaration, it seems much more helpful to switch schema-awareness on at that point rather than tell the user that the declaration isn't allowed because the processor isn't schema-aware.
(c) But we process static expressions during the initial parse of the stylesheet, so there is no opportunity to look ahead to see if there is going to be an xsl:import-schema declaration.
One solution might be to commit to a decision on schema-awareness the first time the question comes up, and then stick to it. So if there's a call on system-property('is-schema-aware'), then if nothing has been said in advance, we make a decision at this point: typically "yes" if we're running EE with a license (and not with target="JS"), "no" otherwise. This is on the assumption that if the user is asking the question, they have written code that will benefit from the answer being "yes"; it also better reflects the W3C approach that schema-awareness is a property of the "processor".
Updated by Michael Kay almost 8 years ago
- Fixed in Maintenance Release 9.6.0.3 added
First thing we ought to fix is that when -sa is specified on the command line, use-when is still saying schema-aware=no. It seems that the Compilation object has schema-aware=yes, but it contains a packageData object that says schema-aware=no.
This can be fixed in Compilation.setMinimalPackageData() by ensuring that schema-awareness in the PackageData is set according to the value in the Compilation.
Secondly, if an xsl:import-schema declaration is encountered during the use-when filtering phase, we should take the opportunity to do Compilation.setSchemaAware(true), so that use-when tests in subsequent elements will get the value true.
Thirdly, when we encounter an xsl:import-schema during the (subsequent) component processing phase, we are setting Compilation.schemaAware(), but this is not reflected in the StylesheetPackageEE object representing the compiled stylesheet, which has the externally requested value. This should be updated.
With these change I think it will work sensibly most of the time. The only exception is if -sa is NOT set externally, then any use-when call on system-property('is-schema-aware') that appears before (or around) an xsl:import-schema declaration will get the answer NO, whereas any subsequent call will get the answer YES. I think we can probably live with that.
Updated by Michael Kay almost 8 years ago
- Category set to XSLT conformance
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.7, 9.8 added
- Fix Committed on Branch 9.7, 9.8 added
- Fixed in Maintenance Release deleted (
9.6.0.3)
Fixed as described.
Updated by O'Neil Delpratt almost 8 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.15 added
Bug fix applied to the Saxon 9.7.0.15 maintenance release
Updated by O'Neil Delpratt over 7 years ago
- Fix Committed on Branch trunk added
- Fix Committed on Branch deleted (
9.8)
Please register to edit this issue