Following discussion during the telcon of April 10, 2014, the WG asked me to come up with a proposal. At that telcon, Michael Kay suggested to allow xsl:catch inside an xsl:stream instruction.

I think that proposal has merit, because it uses existing syntax and has less side effect issues as the proposal in this bugreport (which adds an attribute on-error on xsl:stream)

Here's an outline of the xsl:catch proposal:

Allow the xsl:catch instruction to appear as a child of xsl:stream. It must be the last child element (similar to xsl:try), except for xsl:fallback.

It will have an absent focus for both the sequence constructor and the the select attribute (reasoning: we try to catch an error on reading the input stream, so there will be no node to process).

If this element is present, then, prior to processing the sequence constructor in xsl:stream, the processor must attempt to read and buffer the streamed input document up until the start of the root element (i.e., it must perform the same action that would be required for has-children(root()), as described in bug 25173). If it fails, the appropriate error is raised, which can then be caught by the xsl:catch element.

If the error is not caught, it will bubble up and can be caught by a previous xsl:try/xsl:catch construct and the xsl:stream instruction is not evaluated further.

If the error is caught, the sequence constructor of xsl:catch is processed and the rest of the sequence constructor of xsl:stream will be ignored. No rollback is necessary, because the body of xsl:stream has not yet been processed.

If no error is raised, the xsl:catch instruction is ignored and processing continues as normal.

Notes:
Note 1: this is different from using fn:streaming-document-available, which will not throw an error but simply returns true or false, but has the potential side effect that upon a subsequent read in an xsl:stream instruction using the same URI, it may still raise an error.

Note 2: this instruction cannot be used to catch errors raised by the body of the xsl:stream instruction, it will only catch errors resulting from the initial reading of the streamed input document, i.e. when it fails to construct a streamed document node.

Note 3: this instruction is defined to allow graceful degradation without having to buffer the full result of streamed processing in case of a failure to read the input document. If you do want to catch errors during streamed processing, you can wrap the body of an xsl:stream element inside a regular xsl:try/catch, but this will incur the penalty that the processor will be required to buffer all output, which may be detrimental in certain streaming scenarios.

Note 4: because xsl:catch has absent focus, its sweep and posture are motionless and grounded.

Example:

<xsl:stream href="http://example.org/{$docname}.xml">
    <xsl:value-of select="count(//news)" />
    <xsl:catch errors="err:FODC0005">
       <xsl:text>Invalid docname specified.</xsl:text>
    </xsl:catch>
</xsl:stream>

As an aside: it came to my attention that we do not currently specify the error conditions for xsl:stream in regards to the input document. I assume they are the same as for fn:doc?

I wonder if this can't be done simply by defining an error code that is guaranteed to be used exclusively for errors encountered at the start of the streaming operation, and then catching this specific error with a conventional try/catch instruction around the xsl:stream? I.e. no new syntax, just new semantics for a specific error code?

Re comment 2:

I thought of it, but I think we run into even more trouble, consider:

<xsl:try>
   <xsl:stream href="good.uri">
      <xsl:apply-templates select="x" />
   </xsl:stream>
   <xsl:catch ="err:Special">
      <xsl:message select="'Rolled back'" />
   </xsl:catch>
</xsl:try>

<xsl:template match="x">
   <xsl:try>
      <xsl:value-of select="@y mod @z" />
      <xsl:stream href="{@baduri}">
         <xsl:apply-templates />
      </xsl:stream>
      <xsl:catch select="*">
         <xsl:message select="'What is rolled back?'" />
      </xsl:catch>
   </xsl:try>
</xsl:template>

The second try/catch must somehow differentiate between
1) buffering and rollback current context in case of div by zero
2) poking @baduri for I/O and rolling back without applying templates
3) buffering apply templates and rolling back
4) if halfway streaming getting I/O error, rolling back apply templates

Even though implementations might be able to do this, I don't think it is good to have one construct follow different semantics by one the same syntax and different rollback behavior with potentially the same (I/O) error.

Which is why I presently prefer the (slightly) different syntax (xsl:catch as child of xsl:stream) where the position and focus of xsl:catch makes it unambiguous what is going on and what is going to be caught and/or rolled back.

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.

We could in addition allow recoverable="yes" on xsl:try in the case where the result document is non-recoverable to indicate that a section of code is recoverable (i.e buffering is required) even though the document as a whole is not. (This could also be achieved by using an xsl:variable around that section of code, but there was a feeling that this approach was too non-obvious).

I have written the solution of comment #4 into the spec for the working group to review.

At the telcon on 14 August we studied the new text, and the question was raised again of whether to put the new attribute on xsl:result-document, xsl:try, or both.

On reflection I'm inclined to put it on xsl:try. This has the advantage, originally pointed out in comment 5, that it becomes more visible what the recovery units are, and where buffering might be required to enable recovery.

If we were to add the attribute on xsl:result-document as well then I would propose that this merely acts as a default for the value on xsl:try. However, since the association of an xsl:result-document instruction to an xsl:try instruction is dynamic, this adds another piece of dynamic context information which I think we could well do without. Also, putting the attribute on xsl:result-document makes it messy to define an equivalent for the principal result tree: xsl:output is not really the right place as it's all about serialization. So my proposal is to have it on xsl:try only.

The text of section 24.3 is largely still applicable, though it now becoomes logical to move it to 8.3.2.

The WG accepted the proposal in comment #7.

There was some feeling that the attribute name "recoverable" could be improved. People would prefer something that linked it to the recoverability of the final result tree output, for example recover-output or rollback-output were suggested. It was left to the editor to ponder upon.

The changes have been applied.