This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: RE:read-write same url in xslt 2 [was appendig to multiple output files]
- From: "Michael Kay" <michael dot h dot kay at ntlworld dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Mon, 28 Jan 2002 16:19:39 -0000
- Subject: RE: [xsl] RE:read-write same url in xslt 2 [was appendig to multiple output files]
- Reply-to: xsl-list at lists dot mulberrytech 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