Re: Result set requirements
Robert Barta <[email protected]> Sat, 21 Feb 2004 07:12:33 +1000
| Newsgroups | gmane.text.xml.xtm.tmql |
|---|---|
| Message-ID | <[email protected]> |
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