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

[ac <ac@xxxxxxxxxxxxx>]

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