[tmql-wg] TMQL Proposal

[Kal Ahmed]

On 31 Jan 2005, at 10:19, Lars Marius Garshol wrote:

>
> * Kal Ahmed
> |
> | Graham and I have published a paper proposing a different approach
> | to topic map querying. Rather than define a new query language, we
> | define a relational view of the topic map data model which can then
> | be queried using a standard relational query language such as SQL.
>
> I have read through the paper now, and while I find it interesting I'm
> skeptical about proposing a set of SQL views as the standard TMQL, for
> a number of reasons.
>
> One is that the solutions to the use cases are very complicated
> compared to those for the bespoke TMQLs, and, frankly, the use cases
> are simple queries compared to those generally found in real
> applications.
>

Actually I don't buy either the claim that the answers are complex or 
that all of the TMQL use cases are simple.

The queries presented in the paper mostly use simple JOIN or 
sub-selects - bread and butter SQL stuff. We did use CURSORs in one 
place and as noted in the examples we used DECLAREd variables only to 
enhance the reading of the SQL.

You omit that SQL comes with a whole host of supporting applications - 
not just databases. There are query analyzers, coding environments with 
various levels of integration to databases and so on. This stuff is 
well embedded in the market.

> You've put forward the argument of familiarity as an argument for
> choosing TMRQL, but the solutions to the use cases use advanced SQL of
> a kind that isn't familiar to many developers.
>

Not that advanced. If we had really wanted to dazzle you with 
SQL...well ;-)

> Another problem is that although SQL-92 is a standard, few databases
> actually follow the standard, and so TMRQL would not provide
> portability. If we used SQL-92 we wouldn't need to define ORDER BY
> ourselves, but NULLs sort differently in different databases (etc
> etc), and so portability is compromised.
>

That may be true, but the problem is well-understood. Also how do you 
see the lack of consistent ordering across platforms being a problem 
for anything but conformance tests - what are the real-world use cases 
that demand this ?

> There's also the issue of what people who don't implement on top of a
> relational database (and there are some of those, and likely to be
> more in the future) should do. Requiring them to implement SQL-92 in
> its full glory doesn't seem too attractive.
>

1)  tolog is non-trivial to implement and is incredibly hard to 
implement efficiently.
2) How many non-relational implementations are really of a commercial 
scale ?
3) We propose a system of relational views - I think that is the key 
thing here. If you implement on an XMLDB it would make more sense to 
simply provide the relational views (maybe using indexing features of 
the XMLDB) and then use the underlying system's query language 
(XPath/XQuery/Whatever) to do the queries.

>
> I do think some of your concerns are valid, though, and we really
> should work to ensure that we have a sound conceptual foundation, that
> implementing TMQL isn't too hard, that it isn't difficult to learn,
> and, where possible, that it fits well into existing utilities and
> architectures.
>

You have a good decade of software development to look forward to then 
:-)

>
> The question I'm left with here is: why not just implement a TMQL-to-
> TMRQL compiler? TMRQL makes perfect sense to me as a way to implement
> TMQL, but as the standard I have all the above concerns with it.
>

So you will be creating a TMQL that can be efficiently compiled to 
TMRQL then ? Glad to hear it!

Cheers,

Kal