OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

What Ordering Does XQuery Need? (was:Re: Why not reinvent the wheel?)

I'm not sure the question is "should we include both ordered and non-ordered
return values?"  I think the real question is something like this:

"Should there be ways to specify an order of the result of a query and to
guarantee that this order will be produced?"

Also, there is a second question:

" Should there be a way to guarantee that a returned result remains in the
original document order?"

One reason I'm drawing a distinction here is that, if a query really returns a
set of tree fragments - I mean several separate branches - it's not evident
how to order them.  Ordering by comparing the top level element of each branch
may not be adequate.  Scalar values are one thing, but how to order a variety
of tree fragments?  It's simpler in SQL, you can order by columns where the
compare function is fixed for each column data type.  And document order may
not be meaningful, especially if you are going to pull data from several
documents (like xslt's document() ).

I tend to think that, if no order is specified, that each branch should remain
in document order (where that makes any sense, at least), and that the order
of separate branches should not be guaranteed.

Opinions, anyone?


Tom P

Jonathan Robie asks

> 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"
> >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
>          <result>
>               $e/name
>          </result>