> > 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. ....
> 
> I'm just wondering now why this explanation is not given with 
> the W3C norm. 

It's not the job of a standard or specification to educate its readers or
justify its approach. That needs to be done, but doesn't belong in the
specification. 

> 
> I have another limitation: on my laptop with Pentium M 2GHz, 
> Saxon (Java) takes 100% CPU when calculating things like 
> Sudoku, and you would expect that !
> But on my Core 2 Duo desktop, it does not go above 50%, 
> although it takes CPU on both sides of the processor 
> (according to the Microsoft standard CPU-meter).

That's an interesting observation: I'm not surprised by it, but it's nice to
have confirmation of what I suspected would be the case.

There are currently very few cases where Saxon uses more than one thread.
One the whole, the benefits don't justify the overhead, especially as I
think the most performance-critical workloads are on a server that is
generally doing many transformations at the same time and therefore has
plenty of opportunities to use multiple processors. But there are cases
where using a dual processor more effectively to improve the latency of a
single batch job would be useful, and it's one of those things I will do
when I get a round tuit. 

Michael Kay
http://www.saxonica.com/