# [tmql-wg] Result set requirements

Robert Barta rho@bigpond.net.au
Sat, 28 Feb 2004 19:07:41 +1000

On Fri, Feb 27, 2004 at 12:58:37PM +0100, Rani Pinchuk wrote:
> > 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).

OK, but isn't it ALWAYS the case that - if you would like to convert
from one kind of storage into another kind of storage - there MUST be
something which defines this connection?

In XSLT you have your incoming vocabulary in the 'match' and 'select'
attributes inside XPath expressions and the template body holds the
content according to the outgoing vocabulary.

These might be two different parts of a language, but in an XSLT sheet
these two things MUST be WITHIN one document. Otherwise the whole
transformation does not make sense.

I see this exactly so with TMQL: We have on the incoming side TM
content in a backend store, we detect interesting information with
patterns or predicates, drill further to detail what we want (some TM
path language) and then embed this into an outgoing structure.

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

Yup.

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

What would be the difference between a 'TM slice' and a set of
topics/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.

Hmm, what are 'different' XMLs?

In AsTMa?, for example, I have no problem to create XML output according
to different schemas. I can create

<albums>{
forall $t [$a (album)
bn: $bn ] in$m
return
<album id="{$a}">{$bn}</album>
}
</albums>

I can also create

<guinea-pigs>{
forall ...
</guinea-pigs>

What I cannot see is that you try to separate this into different
documents.

\rho