Re: Result set requirements

> 
> I do not think that we are talking anymore about presentation issues.
> If we say "constructor", then we are talking about constructing data
> structures.
> 
Sure, but I make the separation between the part of the query that
determined WHAT is the data, and the other part which determined HOW the
data is delivered (presented or constructed to whatever structure etc).


> I see it here as a aut-caesar-aut-nihil (all or nothing) question. It
> is difficult to sell to an engineer that - to get an occurrence - he
> has to select a full topic and then (THIS IS NOW OUTSIDE TMQL) drill
> into the topic to get the particular occurrence.
> 
> I would not like that. Either I have a query language which gives me
> access to ALL components of a map, or not.

You are totally right. I find that it is as important to return strings,
exactly because of the reason you gave above. 

> 
> I would rather prefer to have a reasonable way to 'stringify' parts of
> a topic map and to choose (as a developer) whether I want the string
> or the internal data structure.
I understand 'stringify' as returning simple strings (like in SQL) - am
I right in my interpretation? if so:

I totally support that. I find that TMQL should be able to return
strings so it is possible let's say to return simple list of topic base
names. But it should be able also to return topic and association
objects (I would prefer them as light weight nodes). 
What I am not sure about is to have mechanisms in the language that
define HOW the data is delivered. I think it is better to have few built
in formats - strings, Topic Maps slices, and topic and association
objects. If it would depend on me (:-)) I would even not include generic
XML (like the example with generating XML from DTD) within the TMQL,
because I can see situations when the same queries are used to generate
different XMLs.
 
Rani

> 
> \rho
-- 
Rani Pinchuk
Software Engineer
Space Applications Services
Leuvensesteenweg, 325
B-1932 Zaventem
Belgium

Tel.: + 32 2 721 54 84
Fax.: + 32 2 721 54 44

http://www.spaceapplications.com