RE: manage errors and terminations, child thread of R

> 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.

No: xsl:message can output an arbitrary XML document, and the third argument
of fn:error() can be not just a document, but an arbitrary XDM sequence.

> 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? 

You can't guarantee that the arguments to a function are evaluated before
the function is called, but you can guarantee that the values of the
arguments are available to the code of that function. So the error object
might be lazily evaluated, but the fn:error() function will be given enough
information to construct it when required. Of course, if errors occur while
constructing the error object, that's another problem.

(The "information to construct it when required", for some reason, is
traditionally referred to in the functional programming world as a
"closure". I think that's unrelated to the sense in which you are using the
term - but I'm not sure!)

> 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?

Yes, indeed. I think XSLT works best in a very closed functional world where
the output is a simple function of the input. Messy things like telling
security admins what has gone wrong are best handled in a different layer.

Michael Kay
http://www.saxonica.com/