[tmql-wg] Result set requirements

[Robert Barta]

On Thu, Feb 19, 2004 at 08:57:49PM +0100, Rani Pinchuk wrote:
> > From Lars:
> >   - information need
> >   - describe desired result set as query and send of to server
> >   - server extracts result set (essentially a subset of the queried
> >     map) and sends it off to client
> >   - client TMQL library turns (however serialized) result set into
> >     a topic map object
> >   - client uses API as desired
> 
> I am not sure that I understood this - Do you mean that you return
> light topics (so let's say, for a base names query you return the
> resulted topic objects where only their base names are populated), or
> light topic map (so you return full topic objects, but only the ones
> that are resulted from the query)? 

Or both.

Consider the symmetry and its consequences if we allow TMQL also
to generate TMs out off a TM-server:

  - in the simplest case the query simply extracts the requested
    information from the backend and creates a small sub-map with
    all the required information. That is returned to the application
    and that will use a TM API for processing.

  - in the general case the query may create a completely new TM. This
    means that TMQL is a TM-to-TM transformer. The new TM can be following
    a completely different ontology that the original TM.

    [ I once tried an experiment at

      http://astma.it.bond.edu.au/junk/bibtex-use-case.dbk?section=4 ]

> However, if the intention is to generate _different_ XMLs and
> other formats, so custom XMLs for a query, or for an application, 
> I would suggest to create those XML (or other textual outputs) 

Again, this is NOT textual!

> outside of the TMQL engine: The TMQL will generate the result sets, 
> the API will get them, and then in the environment that the user is 
> used to, a generator of XML with that data will be written. 
> 
> What I try to avoid is that TMQL should generate a custom formats like
> the one described in
> http://www.y12.doe.gov/sgml/sc34/document/0449.htm#id2612104.
> 
> The reason is that I think that the scope of TMQL should be retrieving
> data from Topic maps and not generation of XML from data.

But _generating data_ is one of the main tasks of a query language.

SQL does this:

   SELECT name, age FROM ....
   ^^^^^^^^^^^^^^^^

   generates a new table

XQuery does this

   let $authors := /book/author
   return 
      <AUTHORS>
      {
         $authors
      }
      </AUTHORS>

   generates new XML

So why should not TMQL generate something which the application
can directly post-process?

And pretty much every major DB vendor now allows the generation of XML
__DIRECTLY__ from the data. Exactly because it is such a frequent
operation and creating XML 'manually' is booooooooooooring. :-)

\rho