Project

Profile

Help

Bug #3892

closed

xsl:message fails if outputting a function item

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

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

100%

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

Description

The specification for xsl:message states that it constructs a document using the rules for constructing complex content, which would normally cause an error if the content being output includes a function item (other than an array).

However the specification also states "Any dynamic error that occurs while evaluating the select expression or the contained sequence constructor, and any serialization error that occurs while processing the result, does not cause the transformation to fail; at worst, it means that no message is output, or that the only message that is output is one that relates to the error that occurred." - the wording "at worst" here suggests that the actual output is implementation-defined, but the instruction must not fail.

There appears to be no provision to implement this rule in Saxon. This applies also to the example in the spec, where xsl:message outputs a free-standing attribute node.

Actions #1

Updated by Michael Kay over 5 years ago

I have raised a W3C bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=30283 against the test suite. (This is something of a formality since there is no active WG to consider the bug, but it allows me to fix the relevant tests and link the fix to the bug report).

Actions #2

Updated by Michael Kay over 5 years ago

I have revised test message-0001 so it actually does what was intended, outputting an attribute node in xsl:message. The test succeeds, in that the transformation does not fail, however the Saxon code is written (in class MessageAdapter) to inject a processing instruction node to represent the attribute value, and this is not being output as intended (instead the output is a blank message).

Actions #3

Updated by Michael Kay over 5 years ago

I have revised test message-0404 (which does an integer divide by zero while evaluating the xsl:message content) so that (a) the test is XSLT 3.0 only, and (b) it no longer permits the transformation to fail. I have fixed the Saxon implementation of xsl:message on the 9.8 and trunk branches so it recovers from a dynamic error evaluating the message content and outputs instead a message indicating the error that occurred, following which the transformation continues normally.

Actions #4

Updated by Michael Kay over 5 years ago

The try/catch introduced in comment #3 also fixes the original subject of the bug entry: an xsl:message outputting a function item no longer causes an error. I am adding tests that output a function reference, a map, and an array.

I have further changed the code so that MessageAdapter formats a map or function item using the Err.depict() method used for diagnostic output. This works better in 9.9 than in 9.8, but it still gives some indication of the content which is preferable to an error message.

Actions #5

Updated by Michael Kay over 5 years ago

  • Status changed from New to Resolved
  • Applies to branch 9.8, trunk added
  • Fix Committed on Branch 9.8, trunk added

The patch causes a regression in XSLT 3.0 test case result-document-1139. This tests that xsl:result-document fails in temporary output state, specifically while executing xsl:message. However, xsl:message no longer sets temporary output state in XSLT 3.0. The test appears to be wrong, and Saxon is wrong to pass it.

Added a further patch so that xsl:message no longer sets temporary output state, and changed the XSLT 3.0 test case.

Actions #6

Updated by O'Neil Delpratt over 5 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.0.1 added

Bug fix applied in the Saxon 9.9.0.1 major release.

Leave open until fix applied in the next Saxon 9.8 maintenance release.

Actions #7

Updated by O'Neil Delpratt over 5 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.8.0.15 added

Bug fix applied in the Saxon 9.8.0.15 maintenance release.

Please register to edit this issue

Also available in: Atom PDF