[sc34wg3] TMQL, State of Affairs
Mon, 23 May 2005 09:51:34 +1000
Even under the risk that this cannot be properly digested before
Ams'dam, a few short remarks; also in the light of the UK NB position
on the feasibility of TMQL:
- The spec is more or less in itself consistent (well), modulo
the exception where we (Lars and /me) need feedback and guidance
from the committee. Lars will certainly walk through them.
- The parts concerning the _formal_ semantics have NOT been written,
because partly they depend on the above and depend of what happens
with TMRM. Doing this sort of work takes _MUCH_ time, so we want
to do it ONCE only. We do not have the resources like, say, the
- Speaking for myself, I do not have any strong feelings that TMQL
should move forward in the standardization process. More important
to me is the concensus, whether the current draft the way to go or
whether larger changes are to be made.
- Regarding the doubts whether TMQL is implementable, several
- It seems to be. :-)
- The spec should contain enough _informal_ semantics to understand the
machinery (with a few exceptions). It is boring (!) read, I admit.
- Mapping TMQL onto a relational schema simply proves that a TMQL
expression can be mapped into an SQL expression. If we assume that
SQL is sufficiently powerful (Turing complete?), then this proves
Mapping TMQL onto XQuery simply proves that a TMQL expression
can be mapped to an XQuery expression. Otherwise, same argument
- What is probably meant is the scalability of such mappings, but
'Scalability' is a _design_ criterion which may depend on the
application. No computer language 'scales' per se.
Give me _any_ relational database on _any_ database platform on
_any_ OS on _any hardware. I can bring it to its knees.
Give me _any_ programming language on _any_ platform. I bring
it to its knees.
Scale with what, anyway? Number of users? Number of queries per sec? Size
of maps, complexity of maps? Complexity of the inferencing ontology?
Complexity of the query statement?
I guess, it is as it is: Some queries will be fast in a particular
implementation, some will be slow. If someone uses this together
with higher-order inferencing, then queries might not even
The developers/users rule and decide.