[tmql-wg] Result set requirements

Robert Barta rho@bigpond.net.au
Sat, 21 Feb 2004 07:12:33 +1000


On Fri, Feb 20, 2004 at 02:31:08PM +0100, Rani Pinchuk wrote:
> > | As long as this XML/text/HTML is not special for TMQL, I don't see
> > | the advantage of having the definition of generating that format
> > | within TMQL.
> > 
> > If you can demonstrate that the use of TMQL within some other
> > framework does this well I can assure you that we'll listen to you.
>  
> I am not sure what is needed to be demonstrated. I see TMQL used as SQL.
> When there are results set the data from them can be used to generate
> different formats by an application.
> 
> Take for example an application that generate HTMLs from SQL queries.
> I would like to separate the generation of the SQL from the rest of the
> program so the relational database expert can create, profile and
> maintain those queries without touching the rest of the application. The
> programmer who program in certain environment, should not take into
> account the SQL when making calculations over the queries results.
> The graphics person should create/maintain the presentation (so the
> HTMLs) without the need to go into the SQL or the rest of the code...

Ah! I think I sense a possible source of some misunderstanding:

I completely agree with what you say that the separation of concerns
is a pivot requirement. And I definitely agree that the generation of
__SOME__ (=arbitrary) output is not a good idea to have it in the language.

As I understand Lars' TMTL solution, that one allows to use _ARBITRARY_
text and that arbitrary text is returned (to the application or to the
environment).

In AsTMa? we do not allow to "generate arbitrary text". We only allow

  - lists
  - XML as an internal representation, and
  - TM data (again in internal representation)

The only way to get text directly is to have it as part of the list.

I still think that these 3 formats (at least the first two) are widely
used and allow for flexible postprocessing. The inclusion of a "TM
Data Type" simply is added for symmetry.

The application designer will choose what structure suits the results
best. In all 3 cases he can add abstraction layers as you describe
in

> [1]http://jerry.cs.uiuc.edu/~plop/plop2k/proceedings/Pinchuk/Pinchuk.pdf

Hope this clears up a bit what I mean with "generating output". It
is, again, not text.

\rho