[tmql-wg] Result set requirements

[Lars Marius Garshol]

* Rani Pinchuk
| 
| It is obvious that there is a trade off between having the result set
| containing more complex structures and between the simplicity of TMQL.

Absolutely. To me it seems that we probably need to support the
following kinds of result sets:

 - single value,

 - list/set of values,

 - list/set of variable bindings (effectively same as a table), and

 - topic map fragment.

There are situations where all of these are needed, I've found when
developing topic map-based applications.
 
| 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'.
 
This need not be a problem. tolog already does this, and it works
fine. Our query engine even infers the type(s) of each column, and it
all works just fine.

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

I think it's perfectly OK for the query language to say that the order
is undefined. If the user asks for ordering there should be an
ordering rule for each type. This should actually be quite
straightforward.

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

There you have an interesting question: should you get one row for
each base name, or should the QL support collections as values? I can
see arguments both ways.
 
| 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?

Good question. I think the user should be allowed to choose. (This is
how tolog does it at present.)

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

Yep. The data model handles this for you, though.
 
| 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.
 
| So I would like to ask what are the advantages for supplying the
| result sets in "different types".

It depends on the usage situation, really. Quite often when developing
a web page, for example, you want the person who last modified this
topic. That's a single value.

Other times you want all the versions of this topic. That's a list.

And sometimes you want all the versions of this topic with their
version numbers, the person creating them, and the creation times.
That's a table.

And, finally, sometimes you want to create a fragment of a topic map
in order to export it (so user X can take his personal data
elsewhere), to send it across the network (so the graphical visualizer
can show a part of the topic map, or so application X can access TM
server Y), and so on.

So I see important use cases for all of these. (Hope I understood your
question correctly.)

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