This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have a statement in section 2.9 which seems surprising in the light of recent decisions: As with other aspects of serialization, the handling of serialization errors is implementation-defined: see 20 Serialization. Similarly, section 20 starts out: Stylesheet authors can use the xsl:output declaration to specify how they wish result trees to be serialized. If a processor serializes a final result tree, it *should* do so as specified by these elements; however, it is not *required* to do so. (Concerning handling of serialization errors, section 20 passes the buck back to section 2.9) We may want to review whether we intended to be a bit more prescriptive. Michael Kay previously raised as http://lists.w3.org/Archives/Member/w3c-xsl-wg/2005Oct/0005.html
*** Bug 2540 has been marked as a duplicate of this bug. ***
The XSL WG discussed this comment at its meeting on 8 Dec 2005 and agreed with the general sentiment: the specification should be more prescriptive about the handling of serialization in general, and serialization errors in particular, to reflect the decisions that had been made in the past on these topics. The editor was asked to propose specific textual changes. Proposal: 1. In section 2.9, change As with other aspects of serialization, the handling of serialization errors is implementation-defined: see 20 Serialization. to If the processor performs serialization, then it MUST do so as specified in 20 Serialization, and in particular it MUST signal any serialization errors that occur. (This change will automatically cause item 5 in appendix F to disappear) 2. In section 20, change Stylesheet authors can use the xsl:output declaration to specify how they wish result trees to be serialized. If a processor serializes a final result tree, it *should* do so as specified by these elements; however, it is not *required* to do so. to Stylesheet authors can use xsl:output declarations to specify how they wish result trees to be serialized. If a processor serializes a final result tree, it *must* do so as specified by these declarations. 3. Delete the note at the end of section 20, which refers back to section 2.9 for handling of serialization errors. Replace it with the following text: "If the processor performs serialization, then it must signal any serialization errors that occur. These have the same effect as non-recoverable dynamic errors: that is, the processor must signal the error and must not finish as if the transformation had been successful."
Need to change "If the processor performs serialization, then it must signal any serialization errors that occur. These have the same effect as non-recoverable dynamic errors: that is, the processor must signal the error and must not finish as if the transformation had been successful." to "If the processor performs serialization, then it must signal any *non-recoverable* serialization errors that occur. These have the same effect as non-recoverable dynamic errors: that is, the processor must signal the error and must not finish as if the transformation had been successful." With this change, the proposal was agreed.
This change has now been applied to the spec and the issue is therefore closed.