[sc34wg3] TMQL: Restrict tm-content and xml-content to return clause

[Robert Barta]

On Fri, Feb 27, 2009 at 04:30:55PM +0100, Lars Heuer wrote:
> > So your question "is this really necessary" I reinterpret as asking do
> > we want people to guide NOT to use this orthogonal feature.
> 
> More or less. It is not the case that I want to dictate what's good or
> what people should use, I wanted to simplify TMQL a bit. TMQL is a
> relative complex beast since it supports Topic Maps and XML, FLWR
> clauses and select clauses etc. I know you can break down everything
> to the path language, but it is still a complex thing. And if we can
> make TMQL a bit simpler, we should do it.

I would consider the following:

  - If you do not want to support XML creation as a developer, just
    skip it for the moment. That part is certainly ugly.

  - If you do not want to support CTM templates in the RETURN clause,
    just skip it for the moment. CTM is pretty complex to parse. When
    it is _INSIDE_ a RETURN clause where variables can be used, it
    certainly does not get easier.

    I do not have this implemented. And probably never will.
    
  - The complexity of supporting SELECT and FLWR styles is minimal. In
    fact, both can be reduced to one and the same thing. A _LOT_ of
    work was spent to make it _THAT_ simple.

  - But if you do not want to to support FLWR, then skip this one(!)
    production. Or the one SELECT production.

> Anyway, if you can express the same in a nested query, my attempt to
> simplify TMQL is not very fruitful. ;)

I'm not saying, it is not possible. But ...

> Sometime I think TMQL tries to do too many things at once instead of
> keeping the focus on one thing: Topic Maps.

... the misconception - I think - is that a query language such as
TMQL has much to do with Topic Maps. Or XQuery with XML, or SQL with
tables.

Actually only a miniscule part of TMQL deals with Topic Maps, the part
about navigation. The rest is machinery to _MANIPULATE_ the
content. Content being atoms up to tuple expressions. None of this
machinery is relevant for Topic Maps. That's the same in XQuery,
SPARQL and SQL.

SPARQL - just to look at one comparable language - has 70 productions
and 30 more to cover constants (integers, etc.). TMQL has not even 60.

And don't tell me the Topic Maps data model is simpler that RDF!

And in SPARQL you cannot write for instance this:

  SELECT $p, $b + 1       <---- fails
  WHERE
      { $p a :person; $p :hasBirthdate $b; }

You cannot have arbitrary expression in the SELECT clause! This means
that the application has to do that computation.

> Maybe everything works as it is in TMQL but sometimes I wonder if
> someone has verified that TMQL works with all its bells and
> whistles....

No, no one has.

I have upheld my efforts to implement TMQL for quite some years
(starting from 2003). But after all these years of silence and
desinterest around TMQL, I have no stake in keeping an up to date
implementation.

> XML everywhere, CTM everywhere...

Well, either everywhere. Or nowhere. "Somewhere" means higher
complexity, not lower.

> Next time, we should start with something really simple and let that
> simple thing evolve.... ;)

Yeah.

\rho