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

On Mon, 28 Jan 2002 11:45:06 -0000, Mike Kay wrote:

>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'm not sure what the underlying objection is to allowing xsl:document
behave in 'aggregate' mode (as opposed to 'append' which suggests you
might be able to write to an already existing document).  In other
words, if more than one xsl:document refers to the same output then
the pieces are assembled in the order determined by the main result
tree.  In other words, exactly the same behaviour you would get by
putting your own elements into the result tree and doing the splitting
by means of a SAX filter.

I think the spec already talks about xsl:document in terms of
psuedo-nodes in the result tree, in order to explain what an
xsl:document inside an xsl:variable means.  In specification terms we
are saying that rather than insist that there be exactly one
psuedo-node in the result for a given URI, instead we take the nodes
in order as determined by their position in the result tree.

I don't see that this constrains execution order any more than the
requirement that the result tree gets serialized in the right order.  
OK, so an implementer who has decided to interpret xsl:document when
it is executed is then forced to build the whole tree in sequence: but
that is the result of an implementation decision, not the spec?

What did I miss?

Regards,
Trevor Nash
--
Traditional training & distance learning,
Consultancy by email

Melvaig Software Engineering Limited
voice:     +44 (0) 1445 771 271 
email:     tcn@xxxxxxxxxxxxx

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