[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [saxon] Questions about the `saxon:threads` extens
> On 2 Jan 2020, at 22:28, Dimitre Novatchev dnovatchev@xxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > (1) fn:unordered doesn't relate very well to xsl:for-each because functions can't be applied directly to instructions; it would make more sense, > > > I think, to add a saxon:unordered attribute to xsl:for-each. I don't think it's a particularly easy change to make, given the existing code, > > > though I'm sure it could be done. One question is whether the result corresponds to some permutation of the input sequence, > > > or to some permutation of the output sequence (that is, are the multiple result items corresponding to one input item > > > deliverered in the "correct" order? Getting that right depends on understanding the use cases, and I'm not sure I do... > > > > In this case we need a permutation of the input sequence. > > More precisely, we need fn:unordered($vmultithreadingResults) to produce the items in $vmultithreadingResults in the order that they are being produced The problem there is that before evaluating the for-each in unordered mode, we need to know that all references to the variable don't care about ordering. That kind of analysis isn't impossible, but it's also rather fragile; you only need to add an xsl:message that prints the contents of the variable, and you change the way it's evaluated, with no visibility as to why adding diagnostics has changed the result. A saxon:unordered attribute on the xsl:for-each itself would be much more robust. Michael Kay Saxonica
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|