resuming progress on TAP (also TAP doc outline)

[Douglas Tody]

Hi Pat, All -

If I understand your suggestion correctly Pat, you are proposing
that we drop param query from TAP and just have ADQL, with a separate
discussion of parameter-based queries to be added externally, somehow
referring more generally to any DAL interface (it is not clear what if
anything this would have to do specifically with table access since
the PQ parameters are specific to TAP).  Or maybe it had something
to do with the formatted query language string passed in via the
TAP.QUERY parameter, but in that case the interface would no longer
be parameter based.

An ADQL-only TAP would indeed be convenient for those who only want
ADQL, but unfortunately joint standards such as we need for IVOA need
to support the primary combined requirements and use-cases of all
IVOA partners involved.  Inevitably we will end up with something
somewhat broader in scope which requires compromise from all concerned.

In the case of TAP we have already been over this ground many times
over the past year or more, and I don't see any point in reiterating
all the technical arguments or rehashing agreements already reached.
We agreed in Trieste that TAP would provide both AQ and PQ within
the same service interface, with AQ being mandatory and PQ optional
(a compromise on both our parts).  This agreement has been the
basis of all work since, on both the joint specification and on
related prototyping.  We currently have a draft TAP specification
which reflects this agreed upon scope, which as Bob says is probably
about 95% of the way there.

For our part in NVO we require both ADQL and parameter based queries.
PQ is the highest priority for NVO as it is simpler to use and
implement, directly addresses our primary use-cases (cone search,
multicone/simple stage1 cross-match, region-based queries, simple
filter-type catalog access, table metadata queries, etc.), and can
be implemented rigorously regardless of the DBMS, spatial indexing
scheme, etc., used on the back-end.  ADQL is needed for our more
advanced applications, providing a powerful SQL-based general table
analysis capability, multi-table operations, a much more powerful
expression capability, etc.  In short we need both, with PQ being
needed most urgently, while we continue to develop the more general
but complex ADQL-based query technology.  We have been through this
over and over again and always come up with this same conclusion.

Lets stop wasting time repeating past arguments, and get on with it.
TAP should include both AQ and PQ as already agreed, with each
facility being better suited in certain areas, and with most of the
service implementation common to both.  Both need to be developed
simultaneously to ensure a well integrated interface as well as to
satisfy all of our respective project requirements and priorities.
The result will be a very powerful table access interface, capable of
supporting a wide range of use cases from simple astronomer-written
client applications to sophisticated distributed cross match portals.
The major projects can ultimately provide easy to use service
frameworks which will implement all this functionality transparently
given the same table data, DBMS engine, and spatial query mechanisms
on the back end.

Regarding the TAP specification, we discussed this within NVO again
over the past day or so and support the suggested document outline
the core author group recommended last fall (see attached).  This is
not what ended up on the TWiki page Keith put up, that was an earlier
version.  The more recent version describes AQ and PQ together as
comparable service operations, explicitly listing the parameters
permitted in each operation, and includes explicit discussion of
functionality such as multi-position queries and table metadata
queries using PQ.  While there is more which could be added to this,
it is probably an adequate starting point for a V0.4 TAP working
draft and a subsequent round of prototyping.

 	- Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TAP-outline-Nov27.xls
Type: application/vnd.ms-excel
Size: 17920 bytes
Desc: TAP-outline-Nov27.xls
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090209/9778c2bb/attachment-0003.xls>