[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
But I do not understand why *XTRE1480* is an error!
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 Alain BENEDETTI
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] show the information into, Martin Honnen | Thread | Re: [xsl] Why XTRE1500: Cannot read, Colin Adams |
Re: [xsl] show the information into, Martin Honnen | Date | Re: [xsl] Why XTRE1500: Cannot read, Colin Adams |
Month |