RE: [xsl] Why XTRE1500: Cannot read a document that was written during the same transformation ?

Subject: RE: [xsl] Why XTRE1500: Cannot read a document that was written during the same transformation ?
From: Alain <alainb06@xxxxxxx>
Date: Wed, 30 Jan 2008 19:50:29 +0100
> Why XTRE1500: Cannot read a document that was written during the
> same transformation ?

Because the writing may not have been completed when you try to read it.

This is perfectly understandable once the magic word "parallelism" has been spoken.

Under the same chapter of XSLT2.0 norm (chapter 19.1 Creating final result
tree) there are similar errors also understandable such as:

XTRE1490 or XTRE1495: write twice (or more) on the same file (but the first
file may still be opened due to parallelism, so it could fail)

But I do not understand why *XTRE1480* is an error!

And the reason given by the norm is not very convincing, it just says that
it is: "to ensure that the results are fully interoperable even when
processors optimize the sequence in which instructions are evaluated".

I know it's not the role of W3C to give more details, but if you could
give me some convincing example of over-optimization in the case where
XTRE1480 happens, I would less regret to have had to write a cumbersome
workaround for that.

At the moment, this looks suspicious to me (*a bug of the norm?*), because
I don't see how nesting temporary and final output can result in
parallelism producing wrong result (even if processors where parallelizing
templates... which they don't at the moment).

Also, it introduces a non symmetrical behaviour: transition from temporary
to final has not the same properties as the opposite transition.
I consider that to be close to a *side-effect*, as the same piece of code
with the same input will react differently according to which transition
you are on. Having such a effect on a non-side-effect languages looks quite
strange to me.

I'm also aware of lazy evaluation than can differ evaluation of variables.
A processor could as well differ evaluation of xsl:result-document, as,
for the sequence where it is embedded, it produces no output.

Be even with differing instructions, I couldn't think of a faulty result.
Because of course, if you optimize and differ the evaluation, it is only
valid if you remember the "context" of the differed instruction, and the
current output state (stacked, and not "global", because we do not want
side-effects) would have to be part of that context.

But I'm pretty sure you can help, and point to example where over-
optimization would make XTRE1480 meaningful!

A last word... if it is really an error that can occur only with some
optimisations, why is it a *NON* recoverable error?
A recoverable error would allow "well-written" processors to avoid such
optimisations and cope with the output states nesting. It could also be
a flag you pass to the processor to avoid such optimisations, and get
rid of XTRE1480.

XTRE1480 being non-recoverable is quite unfair... because XTRE1500,
which is perfectly understandable, is in fact recoverable, in case the
processor happens to have closed the written file when you need to read it!
In fact I had transformations where it worked, but I wouldn't rely on
that as you are betting on you're system's current workload when you do
such things.

Best regards

Current Thread