https://www.w3.org/Bugs/Public/show_bug.cgi?id=25174 --- Comment #4 from Michael Kay <mike@saxonica.com> --- In discussion today we came up with the following approach. We add an attribute recoverable=yes|no to xsl:result-document (and to xsl:output for the principal result document). The semantics of this attribute are that if recoverable=yes is specified, then any output written to the result document during the course of an xsl:try must be "undoable" if an error occurs during the xsl:try and is caught. (The implementation for undoing the bad writes might either use a rollback/checkpoint mechanism, or a buffering/delayed-write mechanism). But if recoverable="no" is specified, then the following happens: the processor is allowed to write output to the result document optimistically, and if a failure occurs at a point where it has written output that needs to be undone, then despite the fact that the error was caught, the xsl:result-document instruction itself fails saying in effect that the contents of the result-document are incorrect and unrecoverable. A try/catch around the xsl:result-document instruction can catch this error, and determine that the transformation should continue despite one of its result documents being unusable. If recoverable="no" is specified, then the user can still manually prevent problems by doing local buffering of output using an explicit xsl:variable to hold temporary results; the potential for try/catch to cause result document corruptions occurs only when in final output state. Users can also reduce the risk of xsl:stream causing problems by calling stream-available() to test whether a stream is available before starting to process it. There's still a risk of an I/O error on the stream later, and the choice of whether to buffer output to make this I/O error recoverable is now made at the level of the xsl:result-document instruction. -- You are receiving this mail because: You are the QA Contact for the bug.Received on Thursday, 31 July 2014 10:29:30 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:47 UTC