[TABLE] Re: TAP1.0 Comments

[Guy Rixon]

UPLOAD is defined as part of TAP, so can be used with all query  
languages.

Guy

On 12 Aug 2009, at 10:58, Alberto Micol wrote:

>
> 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/754bb1a3/attachment-0003.html>