DAL/TAP Response

[Douglas Tody]

On Sat, 7 Feb 2009, Keith Noddle wrote:

>> Splitting the two can also been seen as treating param-query as a query 
>> language in it's own right (an alternative language to ADQL) and in my 
>> opinion there is a good case to be made to do just that. There has always 
>> been an idea in the background to allow for use of other query languages 
>> (including pass-through native SQL for power users of specific systems, for 
>> example)...
>> 
>> I have not thought about this in much detail, but considerable clarity may 
>> be gained by formulating PQ as a simple query language and then determining 
>> a consistent way to express it in terms of http-params (obviously 
>> attempting to be consistent with existing practice). Just thinking about it 
>> this way may help to resolve the tension in the current draft spec.
>> 
>> Just a thought,
> And a good one! Anything that brings these elements closer together is worth 
> a lot of thought.

The concept has always been that AQ and PQ are two different ways
of formulating queries (two different query languages if you like),
which share the same execution engine, back end, mechanism for
parameter input and data return, etc.  This is one of the reasons
for integrating both into the same service interface.  It is probably
possible for example for everything in the implementation to literally
be the same once the query has been "parsed" into whatever internal
form the back end processing engine requires.

AQ is the fully general query mechanism, which can in principle do
anything, providing the full power of SQL - but it is complex and
critical elements which we need for astronomy applications are not
yet well enough developed (at least in the opinion of many of us).
There are many details yet to be resolved, such as what ADQL elements
or functionality is optional.

PQ is much more limited but this allows what is there to be precisely
defined so that it can be implemented rigorously.  The most common
astronomical use cases receive special treatment in the interface
(cone search, Roy's "multicone" (multi-position queries), region-based
queries, and simple filter type expressions on individual astronomical
catalogs), simplifying usage as well as implementation.  PQ also 
provides a simple but powerful capability, using the standard table
query interface, to query table metadata.  We should keep it simple,
doing only these things, since we already have AQ for advanced queries.

The end result in the interface the three of us came up with last fall
is still a pretty simple, easy to use interface.  There are only two
main data query operations (AQ, PQ), each of which can support sync or
async execution, with much of the service interface and functionality
in common.  Metadata queries share the same service interface
and functionality.  VOSI capabilities and compliance are provided.
UWS and DAL2 consistency are observed to enable code-sharing etc.

Prototyping is well along for all of these.  What we need most now
is to stablize the draft spec so that all of us can get on with a
second round of prototypes.

 	- Doug