[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: XSLT3.0: Predictable recovery of errors when rollback-output="no " is specified?
From: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 25 Jan 2015 18:59:01 -0000
 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:try rollback-output="yes">
     <xsl:result-document href="{$someUri}">
        <xsl:sequence select="$vResultTree"
     <xsl:catch select="$inCaseSerError"/>

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

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

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

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


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.

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.