[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: RE: 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
url with xslt
> 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

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.