RE: [xsl] manage errors and terminations, child thread of Re: [saxon] T

I would have expected most of these clean-up actions (like notifying users)
to be done in the calling application rather than in the stylesheet itself.
Might be more of a candidate for XProc rather than XSLT?

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: ac [mailto:ac(_at_)hyperbase(_dot_)com] 
> Sent: 25 January 2008 12:11
> To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
> Subject: Re: [xsl] manage errors and terminations, child 
> thread of Re: [saxon] Too many attribute value templates? ++
>
> Hi,
>
> 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.
>
> Cheers,
> ac
>
>
>
>
>
> Michael Kay a écrit :
> > 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
> > http://www.saxonica.com/
> >  
> >
> >   
> > > -----Original Message-----
> > > From: ac [mailto:ac(_at_)hyperbase(_dot_)com]
> > > Sent: 25 January 2008 09:56
> > > To: lists(_at_)fgeorges(_dot_)org; 
> > > xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
> > > 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?
> > >
> > > Thanks.
> > > Cheers,
> > > ac
> > >
> > >
> > >     
> > > >   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...
> > > >
> > > >   Regards,
> > > >
> > > > --drkm
> > > >
> > > >       
> --~------------------------------------------------------------------
> > > XSL-List info and archive:  
> http://www.mulberrytech.com/xsl/xsl-list
> > > To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> > > or e-mail: 
> > > <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
> > > --~--
> > >
> > >     
> --~------------------------------------------------------------------
> > XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> > To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> > or e-mail: 
> > <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
> > --~--
> >
> >
> >   
> --~------------------------------------------------------------------
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> or e-mail: 
> <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
> --~--

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--