On 2 Jan 2020, at 22:28, Dimitre Novatchev dnovatchev(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--