Re: Why not reinvent the wheel?

[Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>]

At 06:33 PM 2/26/2001 -0800, Vasileios Papadimos wrote:

>I am not sure about that (and this is true for XQuery too!)
>One way of enforcing implementation strategies is overspecifying.
>As an example, saying that joins respect the ordering of their inputs,
>pretty much forces us to exclude hash-based join algorithms.
>
>Do we really care about ordering in this case? For "human-readable" documents,
>certainly. For "data-oriented" documents we don't; specifying
>ordering forces us to use a, sometimes slower, nested-loops join 
>implementation.

Would an operator that indicates that order is irrelevant satisfy your wish 
here? Something like this:

FOR $a IN unordered(//author),
         $e IN unordered(//editor)
WHERE $a/name = $e/name
RETURN
         <result>
              $e/name
         </result>

I think this is a real issue. Let me check the issues list....yep, we've 
got this covered in the issue "xquery-unordered-collections", which I 
append. Does this cover what you want?

Jonathan

Issue 25 : Support for Unordered Collections (xquery-unordered-collections)
Originator: Algebra Editors
Locus: xquery
Description:
Does XQuery need features to add support for unordered collections? If so, 
what features are required? In the current draft, "unordered" is a property 
of a list. The user can create an ordered list from an unordered list by 
using SORTBY. The distinct() function not only removes duplicates from a 
list, it also renders the list unordered.
Do we need a function that merely removes the ordered property of a list?
How does the ordered/unordered property of a list affect the semantics of 
operators applied to it?