[tmql-wg] Result set requirements

[Lars Marius Garshol]

* Rani Pinchuk
| 
| What I don't understand is why to create double APIs here: One API
| in TMQL which let us access to the primitives of the topics, to
| structures within the topics or to generate XML out of the result
| set, and yet another API in the environment we work in which
| interfaces with the results of that first API.

I guess by the latter you mean something like TMAPI? If so, I have to
say I'm sympathetic to what you say. I've wondered myself whether a
JDBC-like API might be all that's needed, with no ability to retrieve
TMAPI-like structures, or whether something like TMAPI is indeed
needed. 

Personally I don't have an answer yet, but I don't think this
necessarily affects the form of the query language.
 
| I think that it is a must to have this second API (like JDBC for
| SQL). 

It will be, though I think the first priority is to get TMQL itself.
Once we have that probably updates is the second priority. And once we
have updates, we could start thinking about an API. I think it would
be a good idea, but at the moment I think it's best to focus on the
TMQL itself.

| I also think that when we generate anything else then simple text
| rows, that API becomes as complex as the API of TMQL.

Quite possibly it does, yes. There are a few choices there, but it
could easily wind up this way, I think.
 
| Another issue is the generation of XML (or other textual
| presentation of the results) - there are in different environments
| different ways to generate XML out of data structures. Why TMQL
| should add its own way of generating XML - does that mean that the
| TMQL way is better then the other ways (so people should spend time
| learning how to use that part of TMQL to generate their XML
| results)?

The reason to include this in TMQL is basically that this will be a
very common usage of TMQL, and that if we don't standardize this what
will happen is that everyone will create non-standard mechanisms for
turning TMQL query results into XML/text/HTML. If that happens those
building applications with TMQL will not really be much closer to
interoperability between implementations than they are today.

Also, it's not that the TMQL way of generating XML will necessarily be
any better than other ways of generating XML, it's just that it will
be tailored towards dealing with TMQL result sets. Other ways of
generating XML can't be, simply because they won't be designed
specifically for TMQL.
 
| So I am not objecting that different representations of the results
| are needed. But I think that if the ability to create those
| different representations is included in TMQL, there will be
| unnecessary duplications (two APIs, two XML generators) - so we gain
| nothing but loose in the simplicity of TMQL.

I'm not sure this is a problem, actually. We'll have to see, basically.
We still have quite a few options left open.

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