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

Hi Michael,

In our implementation, the pipeline channels XML streams to the 
applications and as well, the main default result-document stream from 
the application(s) is received and processed by the easily configured 
pipeline content handlers.  An error object is just part of the output 
stream, by default, without requiring any special function.
Although we do not use it, I certainly would not recommend removing it 
from the language.  As a matter of fact, this discussion started on 
trying to evolve error() (and @terminate) and I even proposed an 
additional optional attribute to select a closure function to execute 
before shutting down.
Still, I have to admit that I cannot yet see clearly how error() (and 
xsl:message @terminate) can pass an error object back to the pipeline as 
xsl:message only outputs a string and error() is limited to a qname.
The other question that comes to my mind, is:  if order of execution is 
"unpredictable", how would one prevent shutdown from happening before 
the error object is ready?  If logic and conditions can help here for 
the error object, they could also for application level closures, it 
seems.  Isn't building an error object and passing it to the pipeline, a 
form of closure for the application?  

Architecturally, it seems that a fundamental issue is the "layer split": 
what should be handled by the application and what should be handled by 
the pipeline?
Thanks.
Cheers,
ac



Michael Kay a écrit :
> 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(_at_)hyperbase(_dot_)com] 
> > Sent: 26 January 2008 05:29
> > 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 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(_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 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(_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>
--~--