- From: Alberto Massari <amassari@progress.com>
- Date: Wed, 24 Sep 2003 17:31:33 +0200
- To: Oliver Becker <obecker@informatik.hu-berlin.de>
- Cc: public-qt-comments@w3.org
At 17.20 24/09/2003 +0200, Oliver Becker wrote: > > > I'm sorry, but I don't understand what the *function* > > > fn:unordered really ought to do. > > > > Conceptually, fn:unordered returns an arbitrary permutation of its input > > sequence. > > > > In reality, it tells the optimizer that it needn't go to the trouble of > > getting the input sequence in the right order, because the order isn't > > needed. So it's a true function in terms of the formal semantics, but is > > likely in practice to be treated as an optimization directive. > >I'm not convinced that it is a good idea to disguise this as a function. In my opinion, unordered() must remain a function, because it clearly mark the scope of the directive; that is, you know that all that is inside the parenthesis will be potentially returned in a random order. >Can I expect that > ><xsl:variable name="a" select="some-function()" /> ><!-- perhaps do something with $a --> ><xsl:variable name="b" select="unordered($a)" /> > >and > ><xsl:variable name="b" select="unordered(some-function())" /> > >will always give the same result sequence for $b? They will likely return different sequences; in the first case you are setting $a to contain the result of some-function() forcing all nodes to be returned in document-order; then you are assigning to $b the same sequence, allowing for optimizations (but I guess no implementation will change the order, as changing the order of a given sequence will take more time than doing nothing) In the second example, you are telling the processor "evaluate some-function(), but you can skip all the reordering phases, as I don't care"; so, it could happen that $b in the second example is different from the $b of the first. Alberto
Received on Wednesday, 24 September 2003 11:31:57 UTC