resuming progress on TAP

[Francois Ochsenbein]

Dear all,

I was also refraining from adding more traffic to the discussion list,
thinking about pros and cons of Pat's proposal (a separate document
which describes the parameter query). It makes effectively a lot of
sense of separating TAP and QP conventions, I came to the same conclusion
as Andy's on this point: it adds flexibility to our standards if the core
TAP remains while the parameter query evolves. And I'm pretty convinced 
PQ will evolve: for instance QP does not presently give useful capabilities
for selection on character data; this may be OK for now where we 
consider tables as providing essentially numeric results, but a lot
of important information exists also as strings stored in table columns.

Specifying QP in a separate document promoted as a Rec would in fact
give much more visibility to the QP conventions than a section or an
appendix in the TAP specifications. Moreover if these conventions are
shared by several protocols (cf Aurelien's message), it makes a lot
of sense of doing the effort of preparing this additional document.
The various DAL specs could in turn refer to this common QP, which
will clarify and simplify the implementations of the different IVOA
protocols.

A last comment: if the QP document is short (it's felt that there
are too few things to put therein) --- that should not be a problem,
at least for me: I love short specifications !

Francois


>
>Dear all
>
>I have refrained from jumping in before now because my head is
>spinning : from the technicalities as well as the pyschodrama !
>However, it seems to me that Pat's new proposal - core TAP plus
>documents specifying "payloads" or "capabilities" is absolutely spot
>on, with an important proviso.
>
>This proposal is right not just because it will break the logjam but
>also because it will future-proof TAP. For example if ADQL is revised,
>the TAP document does not need to change; and if someone invents a new
>payload or capability, it can be added without changing the TAP
>document.
>
>However, as many have said it is important that we keep to previous
>agreements.  As well as the QL-mandatory business, it also means that
>we must deliver QL and PARAM versions as a single package. To keep
>this agreement, if we logically decouple them, as I believe we should,
>then the docs for TAP-core, QL defn and PARAM defn must be delivered
>as a single package. QL defn we already have of course.
>
>This means two things. First that the drafts of these docs should be
>presented for comment at the same time (and very soon please !).
>Second, that TAP-core and PARAM-defn should be offered to IVOA/TCG/
>Exec to be approved at the same time.
>
>       andy
>

================================================================================
Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 32
/bin/bash: q: command not found