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

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.
>

Yes, and if such text remains, it needs to be backed by a provided
working example.

Cheers,
Dimitre

> 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.