RE: [xsl] RE:read-write same url in xslt 2 [was appendig to multiple output files]

["Michael Kay" <michael dot h dot kay at ntlworld dot com>]

> 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 see what you're getting at. But it's a bit difficult to define the
semantics formally, I think, without changing the data model, so that the
existence of a secondary result tree is somehow recorded by means of a
reference from its parent result tree.

I did at one stage explore a different processing model in which there was a
single result tree, and xsl:document was treated as a serialization
directive to produce multiple serial output files from a single tree. But
that has complications too, and we abandoned it.
>
> 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.

No, that was at XSLT 1.1. At 2.0 we've changed it to prohibit use of
xsl:[result-]document inside xsl:variable, to avoid adding warts to the data
model.

Mike Kay

  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?
>


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