RE: RE:read-write same url in xslt 2 [was appendig to

a quick summary:
from Evan:
>In practice, the result of the transformation
> could be used to
> replace the original file but only after the transformation
> is complete

from Michael:
>Yes, that's another way we could resolve the issue. It would also deal with
>the problem of a transformation failing after writing a secondary result
>document.

>Saxon currently commits a secondary result document to disk when the
><xsl:result-document/> instruction completes execution, and I suspect Bryan
>was indeed exploiting this fact.

from Trevor:
>it is possible and maybe useful to
>write a processor which writes the output to file as soon as it can,
>in which case document('x') could see a half-written file

from bryan: I was exploiting this fact, as it also seems the most sensible
way of working to me, I've always had conceptual problems with the writing
the output to file as soon as it can, I know it's a good model for speed
optimization but it's hard for me to think about.

>> I can see building the same thing in a two step
>>process, using if
>> in Saxon, saxon:next-in-chain, although this would be rather
>> overkill I
>> think.


>From Michael
>I can't see any way to make "append" access work in a system where the
order
>of execution is undefined. Basically, using multiple output documents
>doesn't remove the requirement to make the structure of the stylesheet
>reflect the structure of the output.

I guess what I'm asking for is that xslt 2.0 should have at least something
like saxon:next-in-chain. I've read through the spec a couple times haven't
seen anything there, or anything that dealt with piping transformation but I
could well have missed it. Is there?


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