[tmql-wg] Result set requirements

[Robert Barta]

On Thu, Feb 19, 2004 at 03:15:40PM +0100, Rani Pinchuk wrote:
> 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.

The APIs I see here have no overlap:

TMQL API:

  - TMQL API: compile a query -> get a query handle
  - TMQL API: execute a query -> get a result handle
  - if the result is a list then
       iterate over the list (lists are native to most programming languages)
  - elsif the result is an XML structure
       do something with that, maybe it is DOM, maybe the implementation offers SAX or pull
  - elsif the result is a TM
       use the TMAPI to walk over this data structure

So there is no overlap I can see.

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

As above, if we stick to the (list/XML/TM) output then there are already
interfaces for dealing with them. No further complexity is introduced.

> Another issue is the generation of XML (or other textual presentation of
> the results)

!!! Hold on !!!

This is _NOT_ a textual generation. That would be rather stupid, because
someone would have to parse this. If I ask for XML data to be returned

   <albums>{
      forall $t [ $a (album) ] in $m
      return
        <album id="{$a}">{$t/bn}</album>
   }</albums>

then it is NOT XML text which is generated. My implementation generates a DOM.

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

No, it is not a "better" way, but it is probably the fastest. You, of
course can also ask for the results in list forms:

  forall $t [ $a (album) ] in $m
  return
     ( $a, $t/bn )

and then generate your XML by walking over the list, but TMQL already can
prebuild parts of the result XML as template which can be quickly cloned
whereas your program code would have to generate the nodes from scratch.

> 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 cannot see any duplication yet, maybe you can elaborate with an
example?

\rho