separating TAP and query languages

[Doug Tody]

Roy -

The multicone (multipos / param query) capability requires much of
the functionality in the basic TAP interface, e.g., table uploads,
output formatting, UWS for large queries, etc.  Furthermore we have
already agreed to separate out the param query functionality into a
separate document.  I warned earlier that this could lead to a big
step backward (separate table access interfaces for ADQL and param,
as we had one year ago), but we really do not want to take such
an enormous step backward and have two different TAP interfaces.

Please lets try to continue to have one TAP, merely with separable
query methods, but with most of the functionality in common.  This does
require however that the param query side of TAP actually do the job,
and fully specify how to do these types of queries within the context
of TAP and table access.  This is not true of the proposed generic PQL,
as we (NVO) noted in the posting by Bob last week.

 	- Doug



On Mon, 23 Feb 2009, Roy Williams wrote:

> Doug Tody wrote:
>>  Roy's multicone is the TAP param query.
>
> This is not the story I see in the TAP document.  The problem is that as soon 
> as we say it is part of TAP, the document says we need full-blown ADQL, which 
> defeats the objective of simplicity.
>
> Like this: "You can ride a bicycle, but only if you have a car following you 
> at all times."
>
> So the only thing we can do is to try and submit Multicone as its own 
> standard, independent of the TAP effort.
>
> If only ADQL were not mandatory.  If only TAP were a family of linked 
> protocols, rather than this monolith.
>
> Roy
>
>