rescue; error recovery facilities needed

Hi

Here's a request for XSLT 2, possibly also applying to XPath 2 and 
related technologies.


Problem Summary:

Current drafts of XSLT 2 / XPath 2 don't provide error recovery 
facilities. This current limitation results in various problems: an XSLT 
application can not finish it's job, even if it could continue after the 
error. The app should be able to deal with error if it can handle it, so 
that the transfomation can continue.


Scenario, Problem Details:

The input document references a file, via facilities specific to the 
input's language (not via generic mechanisms such as XInclude, XML 
external entity references, etc).
The transformation application handles this with the unparsed-text() 
function; here's a snippet:

<xsl:template match="textdata[@fileref]">
   <xsl:variable name="file_abs"
     select="resolve-uri(@fileref,base-uri(/))"/>
   <xsl:copy-of select="unparsed-text($file_abs,'utf-8')"/>
</xsl:template>

If the path supplied by the fileref attribute doesn't point to a file, 
then my XSLT processor raises a fatal error [1], and aborts the 
transformation. Especially in cases where there is no human supervision, 
eg when the whole thing runs on the server, this is inacceptable.

This is a very common scenario.


Solution, Request:

Please add error recovery facilities [2] to XSLT 2 / XPath 2.

The syntax for the mechanism could look like this:

XSLT 2:

<xsl:do>
   <xsl:try>
     <xsl:copy-of select="unparsed-text($file_abs,'utf-8')"/>
   </xsl:try>
   <xsl:rescue>
     <xsl:variable name="message">
       <xsl:text>could not insert </xsl:text>
       <xsl:copy-of select="$file_abs"/>
     </xsl:variable>
     <xsl:message>
       <xsl:copy-of select="$message"/>
     </xsl:message>
     <xsl:comment>
       <xsl:copy-of select="$message"/>
     </xsl:comment>
   </xsl:rescue>
</xsl:do>

An analog mechanism might also make sense as addition to XPath 2.

http://www.w3.org/TR/xslt20/#dt-recoverable-error
"An error that is not detected until a source document is being 
transformed is referred to as a dynamic error. Some dynamic errors are 
classed as recoverable errors. When a recoverable error occurs, this 
specification allows the processor either to signal the error (by 
reporting the error condition and terminating execution) or to take a 
defined recovery action and continue processing. It is 
implementation-defined  whether the error is signaled or the recovery 
action is taken. If the implementation does choose to take recovery 
action, it must  take the recovery action defined in this specification."

I need a way to specify the recovery action to be taken. No matter what 
the processor chooses to do in the absence of this user specified 
recovery action (abort or recover); when a user supplied action is 
present (xsl:rescue), all processors must carry it out if the first 
action failed.


Alternatives

There are various solutions specific to the problem described in the 
scenario. They solve this specific problem, but don't address the 
underlying general issue.

A function resource-exists() for example would solve the problem 
encountered in the specific use case described above, but it would not 
help in all other cases where user supplied error recovery action is 
required.


Use Case:

See Scenario.


Possible Issues:

The "rollback" issue mentioned in [3] should be solvable.

AFAICS, Rollback of the result tree should not be required.

One possible solution might be:

Any action contained in xsl:try is only carried out if the complete
contents of the xsl:try succeed.

If one or more action fails, then none of them are carried out.

They are simulated/attempted/tested first, without affecting the result 
tree. This can represent a performance penalty, but where reliability 
and predictable program execution is of high importance, this most often 
is acceptable.

Then the actions contained inside xsl:rescue are carried out.


Discussion:

Please also see
http://www.biglist.com/lists/xsl-list/archives/200306/threads.html#00593


Tobi


[1]
http://www.w3.org/TR/xslt20/#unparsed-text
http://www.w3.org/TR/xslt20/#d0e16677
"[ERR119] It is a dynamic error if a URI cannot be used to retrieve a 
resource containing text. This is a recoverable error. The processor 
must either signal the error, or must recover by treating the URI as if 
it referenced a resource containing a zero-length string."

[2]
Analog to begin-rescue (eg in Ruby), try-catch, etc in other languages.

[3]
http://www.biglist.com/lists/xsl-list/archives/200306/msg00614.html


-- 
http://www.pinkjuice.com/

Received on Wednesday, 18 June 2003 10:49:11 UTC