RE: Re: A proposal:xsl:result-document asynchronous at

> For the time being such support will be provided by the FXSL 
> monadic implementation.
> 
> Before publishing the initial implementation I'm trying to 
> collect a number of good-use examples, like maintaining 
> state, update-in-place Arrays, IO from external files, 
> synchronous exceptions.

I've seen some examples recently where initializing a Java object
requires two calls: a constructor and an initialization.

<xsl:variable name="x" select="java:object.new()"/>
<xsl:do select="setProperty($x,17)"/>
<xsl:value-of select="$x"/>

Somehow the second instruction has to be forced to happen before the
third. The way I fudge it at present is to write the "xsl:do" as
"xsl:value-of", but I've had to tweak the optimizer so it doesn't skip
the instruction because it recognizes statically that the result is
always empty.

Generally the Saxon optimizer has now got to the level where external
functions with side-effects are becoming very troublesome. I've been
thinking of introducing some kind of construct to force sequential,
unoptimized execution of a sequence of instructions. (And for the time
being, I've overloaded the attribute saxon:assignable="yes" to achieve
this effect).

Michael Kay



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list