[tmql-wg] Result set requirements
Fri, 20 Feb 2004 20:55:19 +1000
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> ]
.. ^^ ^^ ^^
|| || ||
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,
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