[tmql-wg] TMQL Proposal

[Lars Marius Garshol]

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

The TMRQL solutions to the use cases are for the most part brief, but
I do think they are complex, because they are consistently couched in
terms of topic, association, base name, occurrence, etc. The bespoke
languages have solutions written in terms of the vocabulary being
used, instead of in terms of the underlying model. I think that is a
great disadvantage of TMRQL.

In fact, if that wasn't a problem, we might almost as well base
ourselves on XQuery.

As for the queries being simple: I'm intimately familiar with the
innards of at least three commercial topic map projects in completely
different domains. In all of them most of the queries in the
applications are considerably more complex than the use cases.
 
| 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.

I agree with Robert's reply to this: yes, for people who know SQL well
this is mostly straightforward.
 
| 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.

This is true, and this is, I think, the strongest argument for TMRQL,
or an approach like it.

| [SQL portability]
| 
| 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 ?

The NULL issue is just a trivial example of a more general problem.
You could say, for example, that another benefit of using SQL is that
it removes the need for TMQL to define string functions and date
functions and all that, but in fact these differ across RDBMSs. And so
on.

There *are* ways around this, but it does mean that there is
significant portability pain in going for an approach like TMRQL.
 
| 1) tolog is non-trivial to implement and is incredibly hard to
| implement efficiently.

Naive implementations of tolog are not efficient, but that's inherent
in the naive approach to implementing topic maps, really. (This is
pretty much what Robert replied, too.)

In fact, the expressive power of tolog and TMRQL is very nearly
identical, so if TMRQL solves this problem, one way around it is to
compile tolog to TMRQL. That is actually not difficult; my Berlin
paper outlines a way to do it.

| 2) How many non-relational implementations are really of a
| commercial scale ?

non-relational implementations of what? Topic maps? And what's a
commercial scale, anyway?

| 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.

Wouldn't it make more sense to define a standard language that can be
implemented in four different ways:

 (a) compile to TMRQL,

 (b) compile to XQuery/XPath/...,

 (c) native persistent implementation, and

 (d) native in-memory implementation?
 
This has been my personal aim all along, even if it never went into
any of the requirements explicitly. (I argued for it, but lost. :-)

| [LMG wants bespoke TMQL that meets Kal's requirements]
| 
| You have a good decade of software development to look forward to
| then :-)

Well, for those who don't want to take route (c), wouldn't route (a)
still be open?
 
| So you will be creating a TMQL that can be efficiently compiled to
| TMRQL then ? Glad to hear it!

Let me put it this way: I want to do that. So far the committee hasn't
discussed the issue, and so it's not a requirement. I'm all for adding
this as a requirement, though. The question is, if we did add it as a
requirement, would you be any happier? 

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >