Maintenance: Planio will be observing a scheduled maintenance window this Sunday, November 10, 2024 from 20:00 UTC until 21:00 UTC to perform important network maintenance in our primary data center. Your Planio account will be unavailable for a few minutes during this maintenance window.
Bug #4037
closedXSLT 3.0 test case error-FODC0002a failing under some circumstances
100%
Description
When the test suite is run with options -bytecode:100 -export:on, test case error-FODC0002a is failing.
Specifically, the test expects an error but we only produce a warning. Somehow the configuration options are set so that document() on a non-existent URI is producing a "recoverable error" - a vestigial XSLT 1.0/2.0 concept.
It could be simply a test driver issue.
Updated by Michael Kay almost 6 years ago
It's treating the FODC0002 error as a warning because Controller.getRecoveryPolicy() is set to RECOVER_WITH_WARNINGS.
This behaviour for the document() function is still permitted in XSLT 3.0: If an error occurs during evaluation of the docFO30 function, the processor may either signal this error in the normal way, or may recover by ignoring the failure, in which case the failing URI will not contribute any nodes to the result of the document function.
The test metadata, however, specifies <ignore_doc_failure satisfied="false"/>
This is causing the recovery policy to be set to DO_NOT_RECOVER on the CompilerInfo. However, the recoveryPolicy on the PreparedStylesheet isn't set from this value.
The s9api XsltCompiler wraps a CompilerInfo with the correct recoverPolicy = 2. We call loadExecutablePackage() on this XsltCompiler to create an XsltPackage which knows nothing of the recovery policy. Then we call link() on the XsltPackage, which creates the PreparedStylesheet and wraps it in an XsltExecutable.
The link() method in fact creates a new CompilerInfo, using the default compilation properties on the Configuration, rather than those used to compile the package.
Changing the XsltPackage to retain a reference to the XsltCompiler, and using this to get the original CompilerInfo, solves the problem.
Updated by Michael Kay almost 6 years ago
- Status changed from New to Resolved
- Priority changed from Low to Normal
- Applies to branch 9.9 added
- Fix Committed on Branch 9.9 added
Updated by O'Neil Delpratt almost 6 years ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.1 added
Bug fix applied to the Saxon 9.9.1.1 maintenance release.
Updated by O'Neil Delpratt almost 6 years ago
- Status changed from Resolved to Closed
Please register to edit this issue