resuming progress on TAP

[Keith Noddle]

> 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

-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Skype:  keithnoddle
Leicester                       Email:  ktn at star.le.ac.uk
LE1 7RH, UK                     Web:    http://www.astrogrid.org