- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 13 Dec 2005 11:41:40 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2469 ------- Additional Comments From mike@saxonica.com 2005-12-13 11:41 ------- 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."
Received on Tuesday, 13 December 2005 11:42:30 UTC