[TABLE] Re: TAP1.0 Comments

[Alberto Micol]

On 20 Jul 2009, at 21:24, Patrick Dowler wrote:

> 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. [...]
> 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.
>


Regarding the above described symmetry, there might be a problem in  
par 2.3.5.

In par 2.3.5 there is a table upload example to specify how a multi- 
position search might work using PQL.
(btw, it is a pity there is no dedicated paragraph to the multi- 
position search topic).

The last sentence of 2.3.5, regarding multi-position queries, reads:
  "it is up to the service to pick up suitable position column(s) from  
the uploaded tables",

What if the uploaded table has got multiple positions (as in the case  
of a result of a TAP join)?
Wouldn't that  break the ability to upload a TAP result to another TAP  
service?

It would be much better to allow the user to specify which coordinate  
pair to use.

Alberto