[sc34wg3] TMQL: limit / offset

[Robert Barta]

On Sat, Feb 28, 2009 at 05:41:56PM +0100, Lars Heuer wrote:
> >> SQL is quite widespread, so disallowing the order that SQL uses (and
> >> SPARQL allows) doesn't seem like a good idea to me.
> >>
> >> Allowing both orders is fine.
> [...]
> 
> I support that proposal.

Duly noted. And I don't think that many more people will weigh in ;-)

> > We can do that, so instead of a
> [...]
> > PS: And now I only need someone remark, that we "should make the
> >    language simpler". >:-}
> 
> Hmm.... These comments are neither funny nor helpful.

I can see that you do not find that funny.

> TMQL is a complex language. And we're talking about two levels here:
> - Simplifying TMQL (i.e cutting support for XML)

What is definitely possible is to drop larger parts in the beginning
and _still_ have something working and useful. That is what I did when
implementing, and others would probably too.

I have never written this down somewhere, but you can implement the
language bottom up

  - atoms
  - navigation (only exposure to map)

Here you actually have already _some_ useful functionality.

  - value expressions (without path expressions)

  - path expressions
  - flwr without XML, CTM (trivial, once you have path expressions)
  - Select (trivial, -- " -- )

  - optimization, optimization

The last step took me the longest. And finally

  - RETURN with XML (surprisingly simple, except the XML parsing)
  - RETURN with CTM (pretty ugly and complex, but doable in a week or two)

And the other thing never really written down, is that TMQL *only*
works with *one* data structure: the tuple sequence. So something
like

   [
    [ 2, 3, 4, 5, 6, 7 ],
    [ 2, 3, 4, 5, 6, 7 ],
    [ 2, 3, 4, 5, 6, 7 ],
    [ 2, 3, 4, 5, 6, 7 ]
   ]

*Every* operation in TMQL is an operation on that. Only the navigation
is operating on the underlying map. Do not underestimate tuple
sequences, though.

> - Make TMQL more userfriendly (i.e allowing SQL-ish constructs and a
> more modern syntax)

Ok, I admit I have difficulties to use "user friendly" and "SQL" in
one sentence. But different people see this differently.

> Allowing the SQL-ish way to express the limit / offset clause does
> not add much to the complexity of TMQL.

I appreciate that you appreciate _that_.

\rho