On 11/03/2011 07:08, Vladimir Nesterovsky wrote:
xsl:iterate works but it's limited to a single level of iteration, as
this way one cannot easily collect output from nested transformations.
Yes, that's correct. The use case for a single recursive tree walk of
the input that delivers multiple results was one that the WG found
particularly taxing; we tried many different design approaches. The
solution currently in the spec (but not yet implemented) is xsl:fork,
which essentially allows you to do several traversals of the input tree
"in parallel", each delivering a separate result. This could be
implemented using multiple threads but it doesn't have to be; the key
idea is that there are several activities/processes listening to the
same stream of events during a single pass of the input. (I'd love to
have a language with native coroutine support for implementing this.)
The results of each activity/process (other than the first) will
typically need to be buffered in memory so they can be assembled in the
right order in the result tree at the end of the input scan - unless of
course each activity writes to a different destination using
xsl:result-document.
Michael Kay
Saxonica
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--