[tmql-wg] Result set requirements

[Robert Barta]

On Thu, Feb 19, 2004 at 10:50:28AM +0100, Rani Pinchuk wrote:
> When the syntax of the language provides the ability to get for example
> the base name of a topic, next to a topic object, it brings up some
> confusing problems:
> 
> 1. Different columns in the result set have different type - base name
>    column probably will be of type 'string', while topic columns will be
>    of type 'topic object'. 

I would have no problem to get as result a "list of tuples", where
every tuple value has a different type, e.g.

   1. Match:   [ 23, "Rumsti", <some topic node> ]
   2. Match:   [ 42, "Ramsti", <some other node> ]
   ..            ^^    ^^           ^^
                 ||    ||           ||
                 number||           ||
                       ||           ||
                      string      map-fragment

We have this in SQL, XQuery, so why not in TMQL?

> 2. If there is more then one base name for that topic, and the scope
>    was not specified it probably means that a list of base names
>    should be supplied. However, it is not clear in which order such a
>    list should be provided. Finally that list of base names should
>    come next to one topic object (in the same 'row'), so we end up
>    with column of type 'list of strings'. 

Not necessarily. Exactly in the same way as other languages we would
repeat the values:

   1. Match:   [ "basename XYZ", <topic node X> ]
   2. Match:   [ "basename ABC", <topic node X> ]

In this __relational__ interpretation of results we always "multiply"
results. That lies in the nature of a relation.

> 3. Should the scopes, and the variants of the base name be retrieved
>    with the base names, so actually a structure is retrieved, or
>    should the base names retrieved by themselves?

I would say the user specifies what he wants and _exactly_ this should
be returned. No hidden magic, no tricks and hidden intelligence.

>    Should we then define different structures for the different
>    sub-structures we have in a topic? For example, when retrieving
>    base name of a topic we get a structure containing base names,
>    their scopes, and their variants.

We could, but this is already done in an abstract way in the TMDM,
or not?

I am rather sceptical about "query languages" which return "nodes" or
other internal data structures. This is like XPath and has the problem
that you have to use XPath _always_ with something else: XSLT, XQuery,
or a programming language.

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

I agree that NOT INCLUDING output data generation makes the language
smaller, but I think we should learn from the experiences in the
XPath/XSLT/XQuery universe and we SHOULD take care that following
principal content models should be supported on the output side:

  - lists for relational data
  - XML for tree-like data
  - TMs for ... voila! TM data

I actually had an earlier version of AsTMa? doing exactly what you say
and found myself repeating the same programming patterns over and over
again.

\rho