Project

Profile

Help

Bug #4037

closed

XSLT 3.0 test case error-FODC0002a failing under some circumstances

Added by Michael Kay over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Diagnostics
Sprint/Milestone:
-
Start date:
2018-11-20
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9
Fix Committed on Branch:
9.9
Fixed in Maintenance Release:
Platforms:

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.

Actions #1

Updated by Michael Kay over 5 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.

Actions #2

Updated by Michael Kay over 5 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
Actions #3

Updated by O'Neil Delpratt about 5 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.

Actions #4

Updated by O'Neil Delpratt about 5 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF