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

["Michael Kay" <mike@xxxxxxxxxxxx>]

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@xxxxxxxxxxxxx]
> Sent: 25 January 2008 12:11
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> 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 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
> > http://www.saxonica.com/
> >
> >
> >
> >> -----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?
> >>
> >> 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