Re: XSLT3.0: Predictable recovery of errors when roll

This is what I came up with:

 <xsl:try rollback-output="no">
   <xsl:variable name="vResultTree">
     .  .  . <!-- Produce output here -->
   </xsl:variable>
   <xsl:try rollback-output="yes">
     <xsl:result-document href="{$someUri}">
        <xsl:sequence select="$vResultTree"
     </xsl:result-document>
     <xsl:catch select="$inCaseSerError"/>
   </xsl:try>

   <xsl:catch select="$inCaseDynError"/>
 </xsl:try>

1. The main processing takes place within the outer <xsl:try> and here
rollback-output="no" is specified.
This means that no efficiency penalty is incurred in producing result
trees ( no need to be able to modify/rollback any result-tree, and
simple output streaming can be used).

2. In case there is an error the variable $vResultTree simply goes
away. This is a buffer in main memory, so nothing has yet been
persisted.

3. In case there is no error in the outer <xsl:try>, we now need to
just produce a final result-document by simply outputting the contents
of $vResultTree into this document. All the processing has already
been done successfully, so the only (most-frequent, like in 99% of all
cases) error that could happen here would be a serialization error.

4. To catch a potential serialization error in 3 - above, we put the
creation of the result-document into a nested <xsl:try> -- this time
with rollback-output="yes" (we realize that a dynamic error almost
certainly will not happen here, so a rollback wouldn't be that
expensive).


Can somebody, please, comment this solution or propose a better one?


Cheers,
Dimitre


On Sun, Jan 25, 2015 at 3:54 AM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> I agree with you, the suggestion of using xsl:variable is not fully worked through and should probably be removed. All the examples I can think of would be more easily handled by using a nested xsl:try/xsl:catch without the rollback-output="no" option.
>
> Michael Kay
> Saxonica
> mike@xxxxxxxxxxxx
> +44 (0) 118 946 5893
>
>
>
>
> On 24 Jan 2015, at 18:53, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
>
>> In section 8.3 "Recovery of Result Trees"  of the 2nd Last Call of the
>> W3C XSLT 3.0 specification
>> (http://www.w3.org/TR/2014/WD-xslt-30-20141002/#recovery), we read:
>>
>> "When rollback-output="no" is specified, it is still possible to
>> ensure recovery of errors happens predictably by evaluating the
>> potentially-failing code in temporary output state: typically, within
>> an xsl:variable. In effect the variable acts as an explicit buffer for
>> temporary results, which is only copied to the final output if
>> evaluation succeeds."
>>
>> I feel rather confused by this statement. There is no example, backing
>> it, provided and my attempts to construct such an example were not
>> successful. I am beginning to think that the quoted statement above
>> may not be true.
>>
>> In particular, how would one verify whether or not an error occurred
>> (and was caught) when producing the result tree contained in a
>> particular variable? Knowing this is needed in order to decide whether
>> to output this variable to the final output or not.
>>
>> My question/request is for anyone to provide such an example.
>>
>> And the document will gain a lot by including such example in it.