RE: rescue; error recovery facilities needed

As posted on xsl list:

From David Carlisle

It's actually an error to refer to a document that is not there. Your XSLT
system may just give up at that point and stop. If so there is nothing you
can do from within the stylesheet.

However the XSLT spec does say what the processor must do if it does not die
at that point: it has to return an empty node set, in which case if
$Description holds the file name, 

<xsl:when test="$Descriptions">
<xsl:when test="count($Descriptions)>0">

both of those should work and be true if the document is there and false
otherwise.

$Descriptions will either be an empty node set or a set consisting of a
single / node, depending on whether the document is there or not.


HTH DaveP.


> I encountered a problem of a somewhat similar nature using XSLT 1.0, 
> using the document function.  In certain scenarios, using 
> Java, the user 
> could make a "document()" reference to a document that might not be 
> there, or might not parse correctly, and I wanted to be able 
> to handle 
> the error in the XSLT, not in the Java code.
> 
> My work-around was to always return a document via the 
> URIResolver, just 
> that sometimes it would have special "error" content.  I 
> mention this in 
> the context of this suggestion to note that it might make more sense 
> with a different syntax.  Two alternatives suggest themselves to me:
> 
> A) Within an "xsl:do" block, have multiple "xsl:rescue" 
> blocks with the 
> appropriate "match" attributes.
> ....
> <xsl:rescue match="errns:notFound">
>     <xhtml:p>Unable to find document</xhtml:p>
> </xsl:rescue>
> <xsl:rescue match="*">
>     <xhtml:p>An unexpected error occurred</xhtml:p>
> </xsl:rescue>
> 
> B) Forgo the "xsl:do" and "xsl:rescue" altogether.  Instead, 
> the xsl:try 
> implicitly does an <xsl:apply-templates /> on the xml of the error 
> message, should an error occur.  Note that the "mode" on the 
> "xsl:try" 
> would be passed through to the <xsl:apply-templates />
> <xsl:try mode="retrieval-error">
>    <xsl:copy-of select="unparsed-text($file_abs,'utf-8')"/>
> </xsl:try>
> 
> Actually, now that I think about it, option (B) seems like a 
> pretty good 
> fit for an extension element if it doesn't end up in the spec.
> Of course, it might make sense for implementations to 
> eventually agree 
> on what the error info-set looks like.
> 
> -Eric.
> 
> Tobias Reif wrote:
> 
> >
> > 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
>
>


- 

NOTICE: The information contained in this email and any attachments is 
confidential and may be legally privileged. If you are not the 
intended recipient you are hereby notified that you must not use, 
disclose, distribute, copy, print or rely on this email's content. If 
you are not the intended recipient, please notify the sender 
immediately and then delete the email and any attachments from your 
system.

RNIB has made strenuous efforts to ensure that emails and any 
attachments generated by its staff are free from viruses. However, it 
cannot accept any responsibility for any viruses which are 
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk

Received on Thursday, 19 June 2003 04:43:13 UTC