W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2003

RE: ORA-FO-UNORDERED 15.1.15 fn:unordered

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
Message-id: <>

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)" />
><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.

Received on Wednesday, 24 September 2003 11:31:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:49 UTC