[tmql-wg] Result set requirements

[Rani Pinchuk]

> Additional syntax makes it easier to learn the language? 
The opposite of course :-) I guess I didn't write it clear if you
understood it that way. Sorry. To be sure we understand each other:
Additional syntax means that there is more to learn so it is more
difficult. So when you go in my funny graph to the right - you have to
learn more. 

> So you would not include functions implementing algorithms in a
> query language to keep it simple?
> 
> If so, then SQL is not simple, because it has functions:
> 
>    SELECT 1+2*3;
SQL indeed includes some functions. It is a question if it is correct 
to include them there - usually you have those functions in any 
programming language that work with SQL. But I guess it is useful to 
have it. Anyway, I meant that SQL doesn't supply much syntax in order 
to implement generic algorithms (like C, Java, Perl etc), and if you add
this ability, you add to its syntax complexity.

> Hmmm, if something COULD be done with the query language, why MUST
> I tell the developer that he SHOULD NOT do it within the query language,
> but with some external program?
It could be done only if the query language supply the syntax for it. 
I just suggest not to supply the syntax. 

A nice example might be the famous CGI.pm module. It contains a lot of 
things. Some more useful then others. Actually I use only the ":cgi" 
group of functions - the group of functions that process the input that 
CGI gets from the browser. But CGI.pm contains also much code for
generating HTML by function calls (which is basically what I don't 
like :-) Now, the question is why a user like me should get the CGI.pm
module as a whole, and have to dive into its huge man page, just in 
order to use quite small part of it. I believe that it would be a lot
better to move the HTML generating functions to other module (and
there are many other modules for generating HTML anyway). 

According to me, the same goes with TMQL - after querying, we have 
to deliver the results. I think we should choose to deliver the results
in the most simple ways that will do, and let other
tools/environment/standards to still process those results. 
 
> To hard-wire the "you-must-factor-everything-into-some-template" would
> mean to patronize. I would not like to go that path. If someone wants
> templates, then he/she should pick one of the 10000000000 templating
> packages and put it an top of TMQL.

Exactly true! This is why I also do not want to "patronize" to the other
side - so to tell the user he must learn how to generate XML (or what
ever else) in ANY OTHER WAY. I just suggest not to include that part in
the TMQL and let the user choose the technique to use according to the
environment that is being used.  

My all argument about separation is coming not to include this kind of 
technique in TMQL, but in order to exclude ANY technique, unless:
1. It is a standard way of doing things.
2. It is impossible to avoid.

Now, you can argue that XML is impossible to avoid, and I actually
accepted this argument (and therefore included possible future feature
like that in the Toma documentation). But I am not sure there is a
standard way of generating XML out of the data of the queries. I am
quite sure that AsTMa and TMTL do not follow such a standard. So I am
afraid that by adding that feature to the TMQL, we add another way to
generate XML and "patronize" the users.


Rani