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(_at_)saxonica(_dot_)com>
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(_at_)saxonica(_dot_)com
+44 (0) 118 946 5893
On 24 Jan 2015, at 18:53, Dimitre Novatchev <dnovatchev(_at_)gmail(_dot_)com>
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.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--