[tmql-wg] Result set requirements

[Lars Marius Garshol]

* Rani Pinchuk
| 
| 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.

I think we'll need access to all objects, actually, and topics and
associations are the heavy objects, so it's difficult to see that
there's any real cost to adding in the other ones as well.
 
| 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.

I think you'll find that in quite a few cases you want to find
finer-grained objects as well. We've certainly needed this.

| This way, the language becomes much simpler, [...]

I'm not sure it does. In the case of tolog we'd have to add
restrictions rather than be able to simplify the language in any way.

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

True, but doesn't this undermine your argument that retrieving the
objects themselves is too costly? (This, by the way, is precisely what
we do today.)

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