RE: result-document from a temporary tree

Hi Michael

> There are several Michaels on the WG, but as this was from 
> you, I guessed it might be for me...

Sorry for any confusion. As the earlier respondent, I expected
that you might pick it up.

> I think the answer to your example is basically the same: yes, the
> restriction is inconvenient. All restrictions that prevent 
> side-effects are
> inconvenient, but the WG believes that they are in the best 
> interests of the
> language.

I certainly endorse elimination of side effects, but the WG line seems to
be shifting. On 26-Mar you wrote: 

"There was a general feeling that outputting a result document
while producing a temporary tree is a side-effect and should not be
allowed; also that it should be possible to achieve the required effect
without doing this."

I think my example demonstrated that it is not possible (within reason)
to achieve a required and sensible effect.

Yes, result-documents are side effects, but everything to do with I/O
and the outside world is a side effect. I might have a program monitoring
xsl:message output and updating a file so that a document() gets dependent
content. So I'm not convinced that avoiding an external side effect makes
for
a consistent justification for more than an inconvenience internally.

> If this rule was removed, you could declare a 
> variable which is
> never used, but whose declaration has the side-effect of 
> creating a result
> document, and we would have great difficulty defining in the language
> semantics whether the result document in that situation is or is not
> written.

Is this like 'volatile' in C? The language cannot understand
the side effect, so it must do as it is told without optimisation.
The possibly redundant result document is written.
 
No. C has an inherently sequential definition, whereas XSLT is declarative.
Examination of the declared possibilities of a Fibonacci type recursion with
added output could give an infinite capacity for output side effects.

The consistent XSLT semantics is surely that external interactions occur
in an implementation dependent fashion, with only those effects
that are necessary always occurring. Others may also occur
in less optimised contexts.

The side effect from an xsl:result-document is potentially the same as
from an xsl:message. Indeed xsl:result-document is really just a more
powerful xsl:message.

> I sometimes find it best to think in terms of a 
> transformation producing a
> single supertree as its output, in which the supertree can 
> contain document
> nodes as children of an element (or other) node. When the supertree is
> serialized, each document node results in a separate serialized result
> document. In fact, at one stage we actually described the 
> processing model
> in those terms (the only problem was that it distorted the 
> data model). When
> you think of it in this way, it becomes quite self-evident 
> that you can only
> create a result document at the point in the processing where you are
> creating its parent in the supertree: the "restriction" then becomes a
> simple and natural extension of the sequential processing 
> model for writing
> a single result tree (you can't update the result tree in situ).

But this is not true of a temporary tree built to a variable, which is
internally transformed and then incorporated into the result tree. The
temporary tree establishes a new internal output context. So the internal
creation context is a stack of output trees; the new temporary tree pushes 
the earlier output tree onto the stack. The same should be
possible for a new external output context.

	Regards

		Ed Willink

Received on Wednesday, 25 August 2004 10:07:10 UTC