Re: Result set requirements

On Thu, Feb 26, 2004 at 03:47:11PM +0100, Rani Pinchuk wrote:
> > 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.


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

Rani,

I do not think that we are talking anymore about presentation issues.
If we say "constructor", then we are talking about constructing data
structures.

Which structures we return, is now a design issue. The more complex
data we allow, the more complex the constructor part will be.

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

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

Exactly my point: I want to get what I ask for.

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

Argh :-))

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.

\rho