Subject: RE: [xsl] RE:read-write same url in xslt 2 [was appendig to multiple output files] From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Mon, 28 Jan 2002 16:19:39 -0000 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] RE:read-write same url in, Trevor Nash | Thread | Re: [xsl] RE:read-write same url in, Trevor Nash |
RE: [xsl] RE:read-write same url in, Michael Kay | Date | RE: [xsl]: Context inside nested fo, Michael Kay |
Month |