TAP pas de deux

[Patrick Dowler]

On Wednesday 18 February 2009 17:59:12 Robert Hanisch wrote:
> We also like the more clear separation of services and payloads.  Thus,
> REQUEST=doQuery (along with the other three) is fine.  LANG is also fine,
> though we might like to replace this parameter with something like METHOD,
> QUERYMETHOD, or QUERYTYPE.  The reason will become clear in a moment.  But,
> this way, we have a parameter that specifies the action, a parameter that
> specifies how the query is expressed, and then the actual query (in the
> QUERY parameter for ADQL, and in the additional parameters defined for the
> param-based query in the new document).

I don't see any problem with renaming LANG to something more suitable. It is 
always a bad idea to imply something that isn't true (or may not be true in 
future) and LANG=PQL does imply something that is not true.

>   We do have some reservations, however, about the notion of turning TAP
> param-based queries into a generic query language that is supposed to
> work across all DAL interfaces.  There are different parameters for

Naming that document PQL (expanded) and using LANG=PQL was a convenient way to 
make the intention of the proposal clear (which I think was successful) with 
a minimal change to the structure of the services being described. I agree 
that P?? is not a fully formed query language in the same sense as ADQL, but 
I also feel we can standardise P?? if we define what it is clearly enough. 

For now, there are many specific issues with P?? (the name included) that we 
can address in separate topics. I will start a few of those today, starting 
with "scope of PQL".

> different purposes depending on whether one is accessing images, spectra,
> or tables.  The same parameter can have different semantics depending on
> the type of data.  (Example:  SIZE, which in TAP defines a circle in which
> to search and in SIAP defines a box that can be the requested size of a

This is, to be blunt, a terrible idea and we really must stop doing it. If we 
want two shapes (circle and box) we must have two parameters. Having a 
parameter mean different things in different places is a bad idea(tm). The 
alternative is to specify the shape on the right-hand side (as is done with 
the REGION param)... Yes, this may well make SIA 2 incompatible with SIA 1, 
but that is what the VERSION parameter is for.

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7