resuming progress on TAP

[Robert Hanisch]

On 2/9/09 7:26 PM, "Patrick Dowler" <patrick.dowler at nrc-cnrc.gc.ca> wrote:

> On Sunday 08 February 2009 19:27:19 Robert Hanisch wrote:
>> 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.
> 
> One way to approach this would be to follow the same strategy that the VOQL
> group did when separating ADQL and TAP: we could specify the "DAL
> parameter-based query language" in a separate document that goes through the
> standards process. It would be usable (referenced) by all DAL services. The
> TAP spec would refer to the ADQL spec as a required language and allow for
> use of other languages.
> 
> Mechanically, the TAP service metadata would have to describe which query
> languages and versions are supported, but we have to do that in any case.
Hi Pat.  I don't think this is quite the right parallelism.  What we did
with VOQL was separate the language from the complex functions that were
layered on the language.  TAP/ADQL and TAP/PARAM are just two variants of
the query.  I'd really like to see them progress together.

>> Francois and Markus have raised some important technical questions.  These
>> need to be addressed and resolved.  
> 
> I think this would also (potentially) address one of the issues raised by
> Markus: param-query can be a pretty complex thing and we may benefit from
> thinking about it and specifying it explicitly. It is easy to think of
> param-query as a simple thing, but in many ways it provides a higher level of
> abstraction that ADQL and I feel it deserves careful thought and design.
I don't quite follow you here either, Pat.  Param is much more constrained
than ADQL.  Param queries are easily fully specified, like cone search and
SIAP.  ADQL is wide open, like writing general statements in SQL, whereas
Param is highly restricted (in order to keep it simple).  I had a
conversation today with a VO service implementor, who commented that
TAP/Param would be easy to do but TAP/ADQL was pretty hard.

> This would decouple the TAP and param-query specs, allowing each to move
> forward at whatever pace can be sustained. It would result in a single TAP
> specification and there would be no particular need to make a new version
> once param is complete. It would also benefit other DAL service
> specifications to have a common spec for param query that can be referenced
> rather than just copying it from one service spec to the next.
I'm quite concerned about this proposal... we worked so hard to reach
consensus on moving ADQL and PARAM forward together, for many good reasons.
We have 95% or more of the work done already.  Think of your government in
Canada, Pat, where all official business is carried out in English and
French.  Your URLs are pretty arcane, but the principle is clear ... the two
languages have an equal status.  In TAP we have agreed to make ADQL
principal and PARAM optional, but they serve the same function and share so
much common infrastructure that there seems no purpose in separating them.

And, we agreed in Trieste to bring them forward together.   And confirmed
this in Baltimore.

Bob