Re: [xsl] Re: xslt 3.0 possible feature - some sort of collection to help when streaming

[Andrew Welch <andrew.j.welch@xxxxxxxxx>]

On 11 March 2011 08:42, Michael Kay <mike@xxxxxxxxxxxx> 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