[tmql-wg] Result set requirements

Thu, 4 Mar 2004 14:06:48 +1000

On Wed, Mar 03, 2004 at 04:40:12PM +0100, Rani Pinchuk wrote:
> > 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.

I buy that also in the sense as saying "there should not be unnecessary
syntax in a language except for places where it might be harmful".

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

Hmmm, I would not dare to take away functions from SQL. We would get
a lot of angry people :-)

> But I guess it is useful to have it.

Uhm, necessary.

The relational algebra is actually built in such a way that you throw
together a couple of relations and you get a completely new one. There
is nothing which says that you only should get some columns of the
original relations.

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

Well, the SQL people are actually working in that direction:

  http://www.jcc.com/SQLPages/jccs_sql.htm#Current Status

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

So you do not want to supply any syntax to generate results?

SQL does it

  SELECT SUM(X), AVG(Y) FROM .....
         ^^^^^^^^^^^^^^
This generates a new relation. It is a "relation constructor".

XQuery (and XSLT) does it)

<html>{
  let $book := document("mybook.xml")/book
  for $ch in $book/chapter
    return <h2>{$ch/title)</h2>
}</html>

This generates new XML.

So why should not TMQL do it, maybe generating TM data, maybe generating
XML and maybe lists.

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

What is the "most simple way"? And: Is the "most simple way" the "best way"?

I am not sure what is "simple" for you, but let us assume as a thought
experiment that we simply process a query and find what the user has looked
for.

Now what? The result of a match can be a set of key-value pairs
(variable => value). We return now this list of matches (one-by-one or
as a whole) to the application. The application then has to deal with
the strings or information items.

That definitely works, but if someone wants this list of results
printed out (in a tutorial, to discuss it with friends, to document
some behaviour, ...)  the result cannot be easily communicated. Only
together with the software (templating if you want).

Imagine this: Every document about TMQL would have to include some 3rd
software to explain how - from the internal representation of the list
- XML and other content is generated.

This is as if the SQL statement would have no SELECT clause. Not
funny.

The other reasoning - I think Lars mentioned this - is that, the more
a query processor can "see" of a query, the more performant it can be.
I have SQL applications where the SQL backend is tortured with
zillions of trivial SQL statements only because the developer never
spend some thought on how this could be done only a few commands.

This luxury of ignorance can be expensive.

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

In my scenario the language would offer relations, XML and TM to be
generated. From all these any application can choose what suits best
for it.

I cannot see too much patronizing here. There is probably more
patronizing involved in using Java or any other of the bondage &
discipline languages.

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

First, as a seasoned Perl programmer I know that there is NEVER a
standard way of doing things. Second, you can also avoid problems if
you saw them coming.

These can hardly be arguments for a language design :-)

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

If you accepted lists and also XML, then there is only a small step to
accept TM constructors. ;-)

> But I am not sure there is a standard way of generating XML out of
> the data of the queries.

No, there is probably none and there also does not need to be one.  In
case of list output, the application can easily process lists (I do
not need to tell this a Perl programmer :-), once it is in XML form,
it can be easily post-processed in most portals nowadays.

For TMs the situation is different, though. Maybe future portals have
a TM infrastructure preinstalled.

\rho