- From: Jonathan Robie <jonathan.robie@datadirect-technologies.com>
- Date: Tue, 19 Nov 2002 08:02:36 -0500
- To: "Bas de Bakker" <bas@x-hive.com>, <public-qt-comments@w3.org>
At 10:13 AM 11/19/2002 +0100, Bas de Bakker wrote:
>You seem to assume that the "sort by" is applied to the whole FLWR
>expression.
Well, I assume that the sort by *may* be applied to the whole FLWR
expression, and often is in queries I see written by a variety of people.
>While this is allowed, I usually use it on the "for" input
>as in my examples in my previous message (or even without a FLWR
>expression at all):
>
>for $x in ... sort by (...)
>return ...
>
>I realize this may be because I'm aware that it is easier to optimize.
Yes, this is a good way of dealing with the way most implementations work,
but it does amount to writing your queries in a particular way because you
know that sort by is, in the general case, hard to optimize when element
constructors intervene between input and output.
>Of course, I can do this with "order by", too. But "sort by" is easier
>to use in other contexts. Instead of
>
>Expr1 sort by (Expr2)
>
>I now have to write
>
>for $x in Expr1
>order by $x/Expr2
>return $x
True - and we discussed whether to keep sort by in addition to the order by
clause. Many people felt that two different ways to do sorting was too much
in a 1.0 release.
>And you will have to spend more time,
>because there is no formal semantics for "order by" yet, which will
>require doing something with tuples and prohibits normalizing FLWR
>expressions to one "for" clause each. (And, in my experience, if the
>formal semantics are more difficult, rewriting for optimization purposes
>is usually more difficult, too.)
I'll leave this for one of the formal semantics people to answer. To me,
though, optimization should be based on a model that allows interesting
orders to be selected from the input.
> > I'm still not at all sure what a 'group' is or should be in
> > the XQuery data model,
>
>I never said I liked the data model. On the contrary, I think it
>severely limits the expressiveness of the language. The difficulty of
>defining "group by" is the most obvious example of this.
> > or what class of problems your users want solved under
> > the concept
> > of 'group by'. Could you fill me in on how you see this?
>
>I don't know whether I can add much to other public comments on this
>topic. The problem is that a query like
>
>for $author in distinct-values(/items/books/book/author)
>let $books := /items/books/book[author = $author]
>return <author name="{$author}">
>{ for $b in $books
> return <title>{$b/name}</title>
>}</author>
>
>is awkward (though admittedly possible) to write, because you need to
>repeat information, in this case the "/items/books/book/author" path.
>This would be easier to write and optimize with a grouping construct
>like
>
>group $books in /items/books/book
>by value $author := ./author
>return ...
>
>where the return clause is evaluated once per distinct author, with
>$books set to a sequence of all books with that author.
Your solution works nicely for this one example, but I'm not sure if it
generalizes. Suppose I want to group by the author's last name, then first
name. How would I do this?
Jonathan
Received on Tuesday, 19 November 2002 08:04:16 UTC