[TABLE] Re: TAP1.0 Comments

[Patrick Dowler]

On Thursday 16 July 2009 01:54:02 Gerard wrote:
> It seems to me that whether one requires support for multiple TABLEs
> depends on the query language that is used.
> If the language allows queries that return multiple tables, then TAP should
> support multiple TABLEs to be returned, but in a single VOTable.
> Currently, if I am not mistaken, ADQL does not support such queries, and
> neither does PQL (correct?).

This is correct. A legal ADQL query will not produce multiple tables. Since 
PQL is under development, it could in principle (and either could in future) 
be extended so that it could produce multiple TABLEs. The wording of this 
section should probably be improved to make it clear that this is not a TAP 
limitation per se, but rather just an indication of what current languages 
actually do.

I think it is important to recall that TAP is  a relatively low-level protocol 
and that the returned results should be as specified by the query. I have 
considered a variety of fancy things one could do to the results (values 
computed from column values, but outside the db, adding extra columns I think 
the user might want, etc) and they all turn out to be really bad ideas that 
will probably break whatever the user is trying to do.

On the other side, it was pointed out that the table UPLOAD is formulated 
assuming a single TABLE resource in the VOTable document. The client specifies 
the name of the table and the content (URI or inline). This would have to be 
completely redone to handle multiple table resources in a predictable way. The 
ability to get a VOTable from one TAP service and UPLOAD it to another is 
critical for building up more complicated usage patterns and we spent 
considerable time establishing the symmetry of input and output VOTables to 
support this. So, even in the future I think it will be very had and likely 
inappropriate to try to include multiple table resource support in TAP.


There was a smaller issue about TAP specifiying TABLEDATA only. I already 
responded that if this is not a useful restriction for making implementation 
easy then the restriction could be dropped.

PS-I will take a stab at Vizier (not literally: attempt to address that case) 
separately

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7