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

["Michael Kay" <mike@xxxxxxxxxxxx>]

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