Re: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++

Subject: Re: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++
From: ac <ac@xxxxxxxxxxxxx>
Date: Fri, 25 Jan 2008 07:10:50 -0500

I am fine with the current xslt2 implementation, especially with an application that manages its error conditions with a formal error/status reference table, with codes, messages, and all that each case may require (like alarms and listeners, for example). The stylesheet's current 20K lines, use @terminate once only, in the error processing/reporting service, after everything that needs to be done is completed, and if the error is fatal.

What may require clean-up before termination, starts from nothing, in many cases and varies depending on application and design in all cases, often including things like notification of users and external or parallel processes, saving cache(s), sessions, session recordings, persistent variables, and/or result tree(s), as well as launching special recovery/security processes and updating/closing databases and communication links.

While the order of execution is unpredictable and closure processes can also run in parallel, logic, sync, and conditions still need to be met for the termination to be initiated. Termination conditions should include closure completion.


Michael Kay a icrit :
Firsly, xsl:message terminate="yes" is I think semantically equivalent to
error(); both cause the transformation to fail with a dynamic error, and to
produce no output. (Though XSLT states that any output produced using
xsl:result-document calls prior to termination may or may not be available
on completion.)

You seem to be looking for some kind of termination that "closes and tidies
everything up" before dying. By that, I assume you mean that you want some
kind of partial output to be available to the calling application? I wonder
if you could explain this idea more clearly - are you thinking perhaps of
some kind of model where everything on the call stack returns an empty
sequence to its caller, bypassing all type checking, and then makes the
half-written result tree available to the application? What would be the use
case for this?

Clearly, one of the rules for xsl:message and error() is that order of
execution is unpredictable, and therefore it's unpredictable how far
execution has proceeded at the time of termination.

Michael Kay

-----Original Message-----
From: ac [mailto:ac@xxxxxxxxxxxxx] Sent: 25 January 2008 09:56
To: lists@xxxxxxxxxxxx; xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++

Hi Florent,

I find xsl:message with @terminate useful, yet, somewhat radical. It might be nice to also pass it a closure function/template(/or selector
of) as attribute/child, to possibly clean things up, in various ways, before dying. error() is fine two but it is just even a little bit more radical. error() may also benefit from the additional closing selector.

Still, the current xslt options are fine, as an application that manages errors, leaves @terminate mostly for testing & debugging, as well as for that application's error management service, after closing and tidying everything up, ready to die. Since tests and debugs may be harder to structure ;-}, and since in such an application, one only shuts down once, error() is probably more useful in other context.

Although interesting, I have some doubts on how much of this is directly related to Saxon. Would you agree that it might now more be relevant on the xsl list, and allow me to throw it there?


If you want a run-time error in this case, you can simply use xsl:message with @terminate or xsl:sequence with error(). I feel
error() is not used often while this is of great help to check some assumptions, while developing and even in production...



Current Thread