[TABLE] Re: TAP1.0 Comments

[Alberto Micol]

On 12 Aug 2009, at 11:00, Guy Rixon wrote:

>
> On 12 Aug 2009, at 09:45, Alberto Micol wrote:
>
>>
>> On 12 Aug 2009, at 00:16, Doug Tody wrote:
>>
>>> On Tue, 11 Aug 2009, Alberto Micol wrote:
>>>>
>>>> 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.
>>>
>>> The issue of multi-position queries is really a PQL issue;
>>
>> mmmh... are you saying that I cannot upload my table of favourite  
>> objects to search for,
>> and use the full power of ADQL to specify more constraints?
>>
>> Alberto
>
> You can, but you would then have to express the position constraints  
> in ADQL too.
>

Exactly what I had in mind.

> You can't mix PQL and ADQL in the same query. At least, TAP makes no  
> stipulation that
> all implementations support this, so you can't assume it for an  
> arbitrary service, and
> doesn't specify a way to denote support in a capability.

Nop, I do not want to mix things. But are you saying that UPLOAD is  
purely a PQL feature?
Or otherwise what is that makes you think I wanted to mix PQL and ADQL
in the same query?

> Of course, if POS, SIZE and REGION were defined to be part of TAP  
> rather than part of PQL then
> we could have more freedom and function.
>
It would be nice, but that would require all languages to support  
them, and this is probably a too strong
constraint.


> Cheers,
> Guy

Thanks,
Alberto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090812/659144c1/attachment-0003.html>