resuming progress on TAP

[Robert Hanisch]

Hi all.  I've been a bit disengaged this past week, as my mother had some
health problems and I had to fly to Wisconsin to be with her.  For some
reason our friends and family do not get sick on schedules that are
convenient for everyone else!

I am pleased to see e-mail from Keith, aiming to get things to closure on
TAP.  I do not see any benefit in revisiting the debates about ADQL only, or
ADQL first and PARAM next.  We saw tremendous progress on the TAP
specification last fall, thanks to the dedicated work of Guy, Doug, and Pat.
We can tweak the presentation, but it is essential, I think, to present ADQL
and PARAM together as alternative query languages, just as Pat has very
nicely described.  ADQL is required, PARAM is optional.  This was agreed in
Trieste.

Francois and Markus have raised some important technical questions.  These
need to be addressed and resolved.  This does not require a reassessment of
the process or of the content of the TAP spec.  Quite the opposite -- the
focus needs to be on clarity and expansion, as necessary, of the
specification.

Ray and Doug have been working hard in the background, refining the document
outline to reflect the overall goal of portraying ADQL and PARAM as query
languages.  They will shortly be sharing this outline, and I hope everyone
will be supportive of this approach.  I believe that it reflects the
concerns raised on the DAL list and in the Interop meetings, and provides a
sound way forward that meets the requirements of AstroGrid, EuroVO, NVO, and
all of our IVOA partners.

In fact, several of the document structures that have been discussed would
meet our collective goals.  Separating ADQL and PARAM, however, would not.
They are simply two facets, two approaches to a common query, and each has
its benefits.  Let's get on, please, with resolving the open technical
questions and getting the document into a structure that makes it as easy as
possible for data providers to implement TAP services.

Bob