[TABLE] Re: TAP1.0 Comments

[Francois Bonnarel]

Patrick Dowler a écrit :
> 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
>
>   
Hi Pat and others,
   I think I understand all the good reasons for the single TABLE output, in the case of ADQL and reloadable PQL queries.
   But having the possibility to request and extension using for example a PQL "Extension" parameter, will allow a lot of use cases we have to be taken into account.
   It would not be a major issue to assume that an output obtained with this feature will not be UPLOADable to another TAP service.
   Structured VOTABLES should not be forbidden in the VO. Model Associations (contrary to aggregations) are not well taken into account by jointures. Not only Vizier and Simbad outputs but also SSA/SIA Extension mechanism (see SSA Recommandation for details) which we use for footprints with Aladin and Virgo are examples of that. Probably GDS, if it is to be implemented in TAP, which I think is a good idea, if we want to extend it to complex data (see DAL2 architecture Note for details of what that means) could take benefit of such a feature.
Cheers
François
  

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel at astro.u-strasbg.fr
---------------------------------------------------------------------