This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
xsl:message is generally used for diagnostics, and it would seem therefore undesirable that the instruction should ever cause a dynamic error (assuming terminate="no"). In particular, the specification says "The xsl:message instruction causes the creation of a new document, which is typically serialized and output to an implementation-defined destination." It doesn't say what happens if the creation of the new document or the serialization of that document fail. Specifically, what happens if the user does: <xsl:message select="@*"/> Saxon 9.0, unlike previous releases, is failing with error XTDE0420 which occurs when you try to create (or serialize) a document node that has attribute nodes as its children. We currently say nothing. We could say that xsl:message MUST NOT or SHOULD NOT fail with a dynamic error, and use words that encourage the implementation to use an implementation-dependent fallback representation is such situations.
Discussed on 31 Jan 2008. There was a range of views, converging on a consensus that we should at least say that implementations "may" treat this as a recoverable error, and leaning towards a "should". Editor asked to produce wording reflecting this.
I propose that we handle this in the same way as errors in patterns (see 5.5.4). Specifically, I suggest that we add to the end of section 17: 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, is treated as a recoverable error even if the error would not be recoverable under other circumstances. The optional recovery action is implementation-dependent. Note: An example of such an error is the serialization error that occurs when processing the instruction <xsl:message select="@code"/> (on the grounds that free-standing attributes cannot be serialized). Making such errors recoverable means that it is implementation-defined whether or not they are signaled to the user and whether they cause termination of the transformation. If the processor chooses to recover from the error, the content of any resulting message is implementation-dependent.
The WG agreed to accept the text proposed in comment #2, with the addition of a suggestion that one possible recovery action is to include a description of the error in the generated message text. Erratum E20 has been drafted.