Subject: RE: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++ From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Fri, 25 Jan 2008 12:16:48 -0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] manage errors and termina, ac | Thread | Re: [xsl] manage errors and termina, ac |
Re: [xsl] manage errors and termina, ac | Date | [xsl] displaying a list in a multi-, Michael Tracey Zellm |
Month |