resuming progress on TAP

[Doug Tody]

Gentlemen -

I really don't understand this proposal and don't see what it
accomplishes other than removal of PQ from TAP.  Presumably we had
agreed, first in Trieste and again earlier this week, that TAP would
include both AQ and PQ, but here we are still spending all of our time
discussing removing PQ from TAP, rather than for example discussing the
technical issues required to get to where we can resume prototyping.
If we go down this route of splitting TAP into two documents I
think we will very likely find ourselves back at square one, with
two separate TAP specifications.  PQ cannot be defined separately
from TAP; as conceived it is an integral part of TAP, sharing most
of its functionality with AQ.  It was never intended to be a general
query language.

If instead we finish what we started, what we will have is one TAP
spec with AQ and PQ as alternate query methods.  If someone does
not want PQ they can simply ignore those sections.  If someone does
want PQ it is clearly specified in TAP, and it is easy to see how
AQ and PQ come together in one service implementation, with much of
their functionality in common.  Those of us who do want PQ will have
something which works robustly now, providing key astronomy specific
functionality such as cone and region searches, multi-position queries
(multicone), and client friendly table metadata queries, while we
continue to develop AQ, which despite what I am hearing is the more
complex and poorly defined part of TAP.  When ultimately all of this
is mature we will have a well structured and well integrated interface
providing a range of capabilities from simple to advanced.

Perhaps we should focus on finishing a TAP 0.4 WD and get on with
another round of prototyping.  If all we have next is a WD it does not
have to be perfect with all issues resolved.  We may be in a better
position to resolve these structural/scope issues once a second round
of prototyping is completed.

 	- Doug



On Fri, 13 Feb 2009, Keith Noddle wrote:

>>  I'm glad to see the people who were reluctant to jump in jumping in.  I'm
>>  also bummed I missed the day it seemed to happen.
> You wait hours for a bus only for three to come along at the same time... :-)
>
>>  I would like to suggest that my core question, what in the previous WDs
>>  are we trying to fix?
> "Fix" is perhaps too strong; "considerably improve" gets closer. I'm sure 
> with enough effort we can push the current WD into REC. However, we have an 
> opportunity to do so much better with no additional effort and no loss of 
> time. I'm sure everyone is striving for the best possible standard that 
> addresses the requirements of the whole IVOA. I guess I've kicked up loudest 
> because I feel it is my duty as Chair to champion these possibilities.
>
> To recap, the proposal is that we separate out the "Payload" from the 
> "Service/Service Interface (aka Protocol)" specification(*). This leads to 
> the following advantages:
>
> 1: We write a simpler, cleaner TAP spec focused on the functions and 
> invocation mechanisms of the Service
> 2: TAP is independent of changes to ADQL and PQ meaning TAP does not need to 
> be re-ratified every time a change to the Payload spec is made
> 3: It is easy to add new Service Capabilities without having to amend TAP 
> (although I guess this is true of any service, somehow the separation makes 
> this cleaner)
> 4: Later, we can examine PQ and see if there are any elements common to other 
> (and future) DAL standards. If so, this means:
>  4.1: Streamlined and simplified service development through code reuse 
> and/or libraries (cf ESAC experience writing DALToolkit)
>  4.2: Simplified Client writing (reduced special-cases on a service by 
> service basis)
>
>>  That's what public review is meant to do: correct problems.  Recognize
>>  also that in doing so, we are stepping backward again.
> Stepping sideways maybe, but not back. This is a reorganisation of the work 
> not an addition or subtraction. As I said above, the same amount of work 
> needs to be done; the restructuring merely changes emphasis not outcome. It 
> also meets Fabio's reiteration of our intent from Trieste that we produce a 
> single TAP standard that encompasses both ADQL and PQ.
>
> Keith.
>
> (*) http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DefiningDalStandards
>
>