resuming progress on TAP
Aurelien.Stebe at sciops.esa.int
Tue Feb 10 09:15:49 PST 2009
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
I hope I managed to express our point of view clearly if not concisely.
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.
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.
More information about the dal