[tmql-wg] Result set requirements

[Rani Pinchuk]

> > 
> > 
> >  --+--+--+--+--+--
> >    single   SQL       XML        Any       algorithms
> >    string   like                Format
> 
> Hmmm, I cannot see different complexities here.
> 
> Whether I say
> 
>    return
>          "Rumsti"   # a string
> 
> or
> 
>    return
>          ("Rumsti", "Ramsti", "Romsti")
> 
> or
> 
>    return
>         <Rumsti>
>             <Ramsti/>
>             <Romsti/>
>         </Rumsti>
> 
> does not make too much difference to me. I am also not quite sure
> what you mean with 'algorithms' above.
Maybe I should emphasis that I speak about complexity in learning the 
language - so in the syntax of the language:

If the query returns ALWAYS one list of strings, there is no use to
include that fact in the query. The query language should not have at
all the select clause (which makes its syntax simpler).

If the query is in the SQL like style, the complexity of the select
clause syntax will be as the one of SQL.

If the query include apart from that also the ability to return XML, 
the select clause should include extra syntax to support also returning 
of XML (like DTD or like the way you do it).

With algorithms I mean that the data from the query can still go through
an algorithm that is written in the query language (which obviously
becomes very generic language at that point). So for example, if the 
data from the query is list of words, the algorithm can be an algorithm
that returns instead the types of the words (verb/noun/adj/adv etc). To
have that, you must program a nice algorithm that identify the words
into their groups.   

> In case of AsTMa we DO NOT expand strings. It is true that we write
> the query as a string (well, of course), but the XML (as well as the
> list and Topic Map constructor) are no text templates, but
> internalized.
I am not sure I understood that. What I meant is that the syntax of
AsTMa suggests that the {$a} and {$b} are strings. So the way it is
implemented is not that relevant for my argument. To put it more clear -
could the very exact syntax of AsTMa be implemented using templates and
expanding strings?


> Sure, sure. But how much have we actually gained and how much lost?
We gained the separation between the languages. You don't have the mix.
It is readable and maintainable. We lost the same we loose when we use
for example OO - some speed in development (at least in the first
phase), and some speed in performance. 


> But isn't that just an XMLish notation of AsTMa? itself? And what happens
> now in case of nested queries?
> 
> <albums>{
>     forall $t [ $a (album)
>                 bn: $bn ] in $m
>     return
>     <album id="{$a}">{$bn}
>     {
>      forall [ (is-producer-of)
>               album: $a
>               producer: $p ] in $m
>         return
>            <producer>{$p/bn}</producer>
>      }
>     </album>
> }
> </albums>

You can implement it as follows:

<albums>
   <while condition="loop_over_albums">
      <album id="$album_id">$album_name
          <while condition="loop_over_producer_of_albun">
               <producer>$producer_name</producer>
          </while>
      </album>
   </while>
</albums>

In your program you query for all the albums ids.

loop_over_albums contains code that gets the next album id, and run a
query over all the producers of that album.

loop_over_producer_of_album contains code that gets the next producer.

The program does not contain the actual queries. It contains KEYS to the
queries that are located in a phrasebook (other file). 

So you have three parts - the XML templates, the Phrasebook with the
queries and the actual program.

I guess the above looks a bit strange when you are not used to it. 
But when your code becomes bigger, this separation makes it much more
clear. 

Try to think about a scenario when you want to make changes after the
application is already done (and big) - how do you change the XML? How
do you change the queries (suppose the topic map structure is changed). 
In the separation approach this will be much easier because there is no
mix in the languages and it is all more readable.

> > So I don't try to avoid running the same query. I try to avoid
> > hard-coding the same query.
> 
> Isn't that exactly what I said above? That 'some pattern P' should
> be in one place and is reused with different constructors?
Yes, but for me the sentence "I try to avoid mixing those two" is more 
important. Exactly like with error messages in English. It is better to
put them outside of your code, in a phrasebook. There are two main 
advantages: 
1. You don't hard code them
2. You don't have in your code two languages: Your programming language
and English. And this makes your code more readable and maintainable.  

Rani