On 11 March 2011 08:42, Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
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.
Interesting.. probably very naive here, but it sounds a bit like it
could be done as the Observer pattern where each observer is a sax
ContentHandler registering itself with whatever is processing the
stream (another ContentHandler) and then for each event, it calls the
respective event on each of the observers.
--
Andrew Welch
http://andrewjwelch.com
--~------------------------------------------------------------------
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>
--~--