Subject: RE: [xsl] manage errors and terminations, child thread of Re: [saxon] Too many attribute value templates? ++ From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Sat, 26 Jan 2008 10:12:27 -0000 |
Without understanding all the details of your architecture - which looks carefully thought out - I would have thought that the right kind of approach is for the stylesheet, on detectable error conditions, to construct an <error/> object of some kind, and throw this object back to the pipeline layer by calling the error() function. Equivalently, you could construct the <error/> object as the content of an xsl:message. If this contains information that needs to be sent to users, to a security log, or to other applications, then the pipeline layer is in a better position to do this than the XSLT code itself. The XSLT code can put as much information as it likes in the <error/> object to steer this process. That's how I would tackle it, anyway. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: ac [mailto:ac@xxxxxxxxxxxxx] > Sent: 26 January 2008 05:29 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: Re: [xsl] manage errors and terminations, child > thread of Re: [saxon] Too many attribute value templates? ++ > > Hi Michael, > > Interesting that you bring this up. First, our xslt app runs > in a platform independent Java-based Pipeline engine that we > also developed to support our xslt efforts. We took great > care in making this design and architecture, first > considering existing and developing solutions > (ex: Cocoon, etc.). One of the key issues that we found is > about the split between the pipeline engine/service and the > applications running in it. There are many issues but a key > one for us is that the split should be well defined and leave > both pipeline (infrastructure) and applications as > independent of one another as possible, yet, supporting the > most sophisticated interactions, including pipeline > re-invocation from applications. > > The pipeline engine manages its processes as well as their > invocation and closure. It also supports HTTP, SOA, Portal > (ex: JSR-168), JMS, standalone, ... sessions, where each > environment can provide somewhat different settings and > requirements, including for closures. The control and > operation of the sessions is then provided to the > applications running in the pipeline(s). > > So back to the application(s) and their closure, in reality, > in most cases, the application can simply shutdown. In some > cases, more actions may need to be taken. An example might > be that the application managing streaming XML content, > detects possible spoofing/corruption in the stream, decides > to shutdown but is required to record the event for further > analysis as well as to notify security monitoring > service(s)/person(s). The spoof detection could also have > happened in a pipeline re-invocation and it might be useful > to signal the nature of the event to the pipeline and other > invocations, before shutting down. > This may also be in a SOA session, for example, where a rich-client > process(es) is(are) waiting for a reply from the/an > application running in the pipeline ... > > Our choice was to use Java to build the (fully XML > configurable) pipeline engine infrastructure and XSLT for XML > content processing and transform applications. > > The next time we build a pipeline engine (or revise this > one), we would also consider Xproc (and Xproc conformance), > but it wasn't there at the time, I am not sure that it is yet > an industrial strength working solution, and I still have not > seen any pipeline engine like ours, which, apart from our own > applications, currently powers industry and government > portals and applications, written in Java, .Net, xslt, etc. > > In summary, it might be that while many aspects of closure > are better dealt with in the pipeline, the pipeline should > not have to be aware of applicative considerations, when they exists. > > What do you think? > > Thanks. > > Cheers, > ac > > > > > Michael Kay wrote : > > 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 wrote : > > 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 | RE: [xsl] Copy Child Elements, Wei, Alice J. |
Month |