Re: Result set requirements

> >
> Constructors have nothing to do with data presentation. They allow to 
> create new objects.
> These objects can be based on TMDM, XML DOM or other data models. They 
> are data structures.
> 
> Pure "select" query languages  do not allow creation of  new objects. I 
> see it as a problem for TMQL.

Sorry for my mistake. However, the constructors playing other role then
querying - Their role is to construct data models from whatever data. 
Among that, also data from TMQL queries. 

If you look at the example you gave, you see there queries which
responsible to WHAT data is delivered, and you see there the constructor
parts which responsible to HOW the data is delivered. 

Now look at the queries only - this is what I would call TMQL. All the
rest, in my opinion, should not be included into TMQL. 

It is not that I find it wrong to write queries within
presentation/construction templates - I think that it SOMETIMES wrong
(usually when the project is big, and you need separation of
responsibilities between the people who work on different domains). 
But if this mixture is built into one language, it means that you cannot
avoid from it in whatever circumstance.

You write that pure "select" query languages do not allow creation of 
new objects. I also find this as a problem - strings are not enough as
result sets. 

But on the other hand I am not sure that TMQL should be able to return
ANY object. And I think that the solution should be within what I call
TMQL, and not outside of it. So I think that the selects themselves
should be able to return something else then just strings - not any
object, but maybe topic nodes and association nodes.

My initial attitude to the whole problem was to return nothing but topic
objects and association objects from the selects. And have in the API
that uses the TMQL (this API for TMQL is like JDBC for SQL) methods that
let us access the different elements in the topics. This way, the
language becomes much simpler, and we can avoid from the above
questions. However, it is true that there are some performance penalties
for this attitude - some topics might hold many big resourceData
elements, and it might be annoying to pay that price for seeing a simple
list of topic ids... 

But this performance problem might be solved in other ways - for example
using the idea that came I think from Jan Algermissen of using light
weight objects - so a topic object that contains only the base name
element and id if we asked to see the base names. 

I wrote some of those ideas for Toma in 
http://www.spaceapplications.com/toma/Toma.html#select_clause__nodes
but note that the idea of constructing XML from DTD there is
conceptually similar to the constructors (so it is again a mixture of
data querying and the way that data is delivered).

Rani