[Bug 25174] [XSLT30] Buffering with xsl:try wrapped around xsl:stream or xsl:result-document

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