Subject: [xsl] 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 |
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.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: XSLT3.0: Predictable reco, Dimitre Novatchev dn | Thread | [xsl] streaming identity transforma, Martin Honnen martin |
[xsl] Re: XSLT3.0: Predictable reco, Dimitre Novatchev dn | Date | Re: [xsl] streaming identity transf, Michael Kay mike@xxx |
Month |