Re: [XSL] Accessing part of the result tree illustrate

On 9/5/07, David Carlisle <davidc@xxxxxxxxx> wrote:
> Such a construct would only really be useful if you could rely on the
> processor evaluating all the items  in a for-each in order, but that is
> explictly not the case. One of the benefits of a side effect free
> language is that it is naturally parallelisable. It's best to assume
> that all the items in a for-each are evaluated in parallel, and the
> results assembled at the end and passed on. If you view it this way the
> fact that you can't "stop" a for-each based on the processing of one of
> the items should seem far more natural. If you need the processing of
> one item to depend on the result of processing another, don't use
> for-each, use a recursive template that processes the item and then just
> conditionally processes the next item if needed.


In this case the for-each iterates over items in a sequence
(xs:integers), which makes me wonder if the same rule applies?

Is it conceivable for a processor to parallelise the processing of a
sequence of atomic values and then reassemble the results in sequence
order, or does that only apply to nodes and document order?


-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/