[tmql-wg] Proposed new requirement: Ability to produce textual output

[Lars Marius Garshol]

* Robert Barta
| 
| I am neither sure myself, but my feeling is that if the query
| processor would return directly the results of one stage to the
| application either the application will have to do this navigation
| with normal API means or use the query infrastructure again.

That's a goal I agree with: the query result returned by the query
should be as close to what the application looks for as possible. If
the application wants the Italian name of every city in Italy in
lower-case in alphabetical sort order the query should be able to
deliver just that.

| In cases of nested loops that can be pretty non-performant:
| 
|    for all things I find put it in $A
|       output something
|       for all things I find in $A/basenames
|          for all topics of type T
|             output something from the topics
| 
| There would be far too much interaction between application and
| query infrastructure.

Agreed, and that's the problem here in general.
 
| I rather wold prefer the query language to be a bit more flexible to
| take over trivial application tasks, that is
| 
|    - loops over results
|    - if based on results
|    - simple navigation from one topic map construct to another
| 
| If the application engineer prefers to do some things 'manually',
| he still can do that. But if the query processor gets a bigger
| query then there is more room to optimize.

I agree with the general principle, but I'm not sure about having
loops and ifs in the language itself. So long as you can express the
intent of your query I must say I don't really care whether that's
done via loop/if or something completely different. In fact, something
different may well be better.

| [navigation and querying]
| 
| Does it disturb you having both in the language?

Not per se, and especially since I believe they are to a large extent
the same thing. What would disturb me is if we designed features for
querying (say, getting all base names of a topic) and then designed
the same features again for navigation (say, getting one base name of
a topic).
 
* Lars Marius Garshol
|
| That might well do the trick if you can interleave that with
| navigation/matching and output production. I tried doing that with
| tolog, but the result was way too painful.
 
* Robert Barta
|
| Hmm, I think once you have commited yourself to an explicit content
| generation phase within the language then an if-then-else or also an
| do-this-or-else-if-that-fails-do-something-else.

Yes. The trick is to find a syntax and a model for it that is
satisfactory, but so far I haven't.

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