[tmql-wg] Result set requirements

[Lars Marius Garshol]

* Rani Pinchuk
| 
| I am not so sure about this point - it might be true that the
| standard should guide the users how to create those formats - so to
| avoid a situation where as you write "everyone will create
| non-standard mechanisms for turning TMQL query results into
| XML/text/HTML".

I think there needs to be a standard way of doing that, because
otherwise we will see a proliferation of such mechanisms. Indeed we
have them already.
 
| I would prefer, though, that this will be outside of TMQL - results
| from SQL can also be turned into XML in non standard mechanisms. So
| maybe there should be other standard for generating textual formats
| like XML text of HTML from data.

This is something we can still choose how to do. Robert has advocated
incorporating it directly in the language, whereas for tolog I did
TMTL[1] which keeps it on the outside. I can see this argument both
ways and personally haven't made up my mind yet.

The jury is still out on this one, and I think Robert and I have more
or less tacitly agreed to wait until we *have* a TMQL, and only then
do we plan to deal with this.

| I am also not sure about the special case of TMQL result sets -
| those will be after all scalars and structures - and there are many
| applications that might have scalars and structures that should be
| turned into XML/text/HTML. 

Oh, absolutely! We can't require all results to be turned into an
output format. 

| 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.
It's not as if we write standards for the fun of it. :-)
 
| So actually I still think that the advantage of having TMQL simpler
| is more beneficial here then introducing the ability to generate
| textual formats from the results.

That's a trade-off, really. Personally I'd like to see this generation
capability layered on top of the QL itself, whether it's external to
the QL (like in TMTL) or internal to it (like in AsTMa?), so that
people can choose whether to implement it or not. The requirements
document is also formulated this way. But we'll do the basic QL first
and then look at this.

[1] <URL: http://www.isotopicmaps.org/tmql/tolog.pdf >

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >