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

[Robert Barta]

On Mon, Jul 21, 2003 at 01:58:04PM +0200, Lars Marius Garshol wrote:
> 
> * Robert Barta
> | 
> | Let's look at XQuery (SQL is such a ... mature language): [...]
> | 
> | In the first for-loop the results is narrowed-in: books with editors.
> | Some results can be directly used from this match like the title. For
> | other some more navigation is done ($b/...go..somewhere../...).
> | 
> | After the navigation phase these results again could be subjected a
> | search or used to build a new search: [...]
> 
> That's a pretty clear explanation of what you mean by having both
> navigational and matching features in the same language, but why did
> you say you think both should be in the language? That's really the
> thing I am unsure of.

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

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.

> Aren't they just really the same operations performed in different
> phases of the query evaluation? Or, to put it another way, the same
> operations performed with different intents?

Yes and no. Navigating from A to B is certainly a query whereas a
rather specialized one. 

Does it disturb you having both in the language?

> * Robert Barta
> |
> | Right, so I simply assume that there should be an 'if' in the query
> | language.
> 
> 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.

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.

\rho