Re: Result set requirements

OK, I understand now the reason for having result set specific for
certain primitives inside the topics. This indeed save sub-queries to
the engine.  

My plan was actually to return all the topics that are in the result
set, but this is also not that good, because when someone looks only
for the base names in certain scope, it might be far too heavy to
retrieve all rest of the topic data (like resourceData that might be
in those topics)...  

Thanks for the explanation. I will have to think how to incorporate
this functionality into Toma. One difficulty is that when we allow
results that are not scalars, we cannot present in proper way the
results (like the nice output tables I have now) - so if I want to
implement it I should already start to think about API in the
environment I code. Any ideas?

> What I currently think is that TMQL should return topic maps and that
> the client will be given a lightweight topic map object that can be
> accessed with the same API as 'big' (normal) topic maps. The query
> process would be something like this:
> 
>   - information need
>   - describe desired result set as query and send of to server
>   - server extracts result set (essentially a subset of the queried
>     map) and sends it off to client
>   - client TMQL library turns (however serialized) result set into
>     a topic map object
>   - client uses API as desired

I am not sure that I understood this - Do you mean that you return
light topics (so let's say, for a base names query you return the
resulted topic objects where only their base names are populated), or
light topic map (so you return full topic objects, but only the ones
that are resulted from the query)? 


> there are in different environments different ways to
> > generate XML out of data structures. Why TMQL should add its own way
of
> > generating XML - does that mean that the TMQL way is better then the
> > other ways (so people should spend time learning how to use that
part of
> > TMQL to generate their XML results)?
> 
> I don't understand what you mean, can you explain more?

Assuming that TMQL is returning always the same XML, then the above is 
not relevant. I actually think that XML might be a good candidate as a 
format for the result set.

However, if the intention is to generate _different_ XMLs and
other formats, so custom XMLs for a query, or for an application, 
I would suggest to create those XML (or other textual outputs) 
outside of the TMQL engine: The TMQL will generate the result sets, 
the API will get them, and then in the environment that the user is 
used to, a generator of XML with that data will be written. 

What I try to avoid is that TMQL should generate a custom formats like
the one described in
http://www.y12.doe.gov/sgml/sc34/document/0449.htm#id2612104.

The reason is that I think that the scope of TMQL should be retrieving
data from Topic maps and not generation of XML from data.

But after reading the reply of Lars to my last email, I am not totally
sure about this point. See my reply to it.

Rani