resuming progress on TAP

[Aurelien Stebe]

Dear all,

please find below the collective view of the ESAVO Team on the recent 
discussions on TAP.

First, the AQ and PQ, as they have been nicknamed, are not interfaces, 
but Query Languages. They have been called both, hence part of the 
confusion. The ADQL was separated from the protocol (which is now TAP), 
for various reasons, which I think we all still agree, were good ones : 
allows parallel evolution of the standards, allows the protocol to 
support other QLs and the QL to be used by other protocols, allows the 
protocol to set it's own level of support of the QL. Param-Query _is_ a 
Query Language, therefore I would place it in another document for all 
the reasons which were valid for ADQL. That should technically justify 
this separation, to answer Ray's excellent question about the 
motivation. Another argument for separation is less technical, but still 
valid in my opinion, and has been repeated many times. As ADQL is 
already a REC, and most of the TAP contributors seem to agree that the 
protocol interface is nearing completion, we could have a TAP v1.0 for 
the May InterOp. The Param-QL, on the other hand, needs more work in my 
opinion (see the following).

Second, the "Simple" DAL protocols have a common QL. We have been 
advancing this idea ever since I tried to write a service that would 
implement both SIAP and SSAP (the DALToolKit). That document should be 
written separately and the next versions of SIAP and SSAP should make 
reference to it, just like TAP makes reference to ADQL. The question is 
: could this be unified with the Param-Query document talked about 
above, maybe. The authors and contributors of SIAP, SSAP and the PQ part 
of TAP could certainly enlighten us on this.

Finally, to state how I would present all this in the TAP document, to 
reply to another good question in a previous email. The vast majority of 
the TAP document should not make any assumption or mention of the Query 
Language which might be used. Asynchronicity, table upload, metadata 
retrieval, VOSI endpoints, output format, error handling, .... can all 
be specified in a QL-agnostic manner. Where the LANG and QUERY 
parameters are specified, it should be stated that ADQL support is 
mandatory, give reference to the REC document and specify, if necessary, 
the level of ADQL support required. A comment could mention the efforts 
in progress on the Param-QL document, which is the recommended optional 
QL to support. When the Param-QL document is ready, and if PQ specific 
comments are necessary in the TAP document, a v1.1 of TAP would be 
prepared.

I hope I managed to express our point of view clearly if not concisely.

Cheers,
Aurelien


Keith Noddle wrote:
>> 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.
> I agree. I like that it frees up the option to relatively easily add 
> other optional querying capabilities (XQuery for object 
> databases/other XML data resources, maybe?) at some point in the future.
>
>> 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.
> This is an improvement on my suggestion, thank you for making it. 
> Working towards a common spec for param based querying makes a lot of 
> sense from the perspective of all the so-called "Simple" access 
> protocols, laying the groundwork for future standards
>
> You have articulated two very powerful concepts here and I think this 
> approach has much merit - more than my original, certainly. It would 
> help to hear comments from other interested parties. Right now I am 
> concerned that the debate is crystallised around the same old names - 
> an injection of fresh ideas would be most welcome.
>
> Keith.
>

================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================