Re: Result set requirements

On Thu, 2004-02-19 at 13:13, Lars Marius Garshol wrote:
 
> | On the other hand, the TMQL could leave the fetching of the actual
> | primitives from a topic object to the programing languages or tools
> | that might use TMQL. In that case the TMQL returns only topic
> | objects (or their ids), and the APIs of different languages will
> | define a way to access the different primitives inside the objects.
> 
> That's how I think it ought to be. TMQL can say what the result set is
> abstractly, and then different APIs can choose different ways to
> represent it.
>  
> | However, also when TMQL supports retrieving of different primitives
> | such APIs will be needed, unless we restrict TMQL to return only
> | simple textual rows (like in SQL) which is for sure not the
> | intention.
> 
> Yep.

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 think that it is a must to have this second API (like JDBC for SQL).
I also think that when we generate anything else then simple text rows,
that API becomes as complex as the API of TMQL.

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)?  

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.

Rani


-- 
Rani Pinchuk
Software Engineer
Space Applications Services
Leuvensesteenweg, 325
B-1932 Zaventem
Belgium

Tel.: + 32 2 721 54 84
Fax.: + 32 2 721 54 44

http://www.spaceapplications.com