TAP Implementation Issues (cont'd)

[Doug Tody]

On Wed, 21 Oct 2009, Tom McGlynn wrote:

> [Third in a series]
>
> 2.3.1 What is a getCapabilities request supposed to do since we don't
> have a capabilities record defined to return?

Ultimately we need to fully specify the Capability record for a TAP
service (ideally directly within the main TAP specification), but we
don't have that yet.  My feeling is that a current TAP service should
implement the getCapabilities interface as specified, but either
return an error response or an as yet nonstandardized, prototype
capability record, which we would need to permit for a compliant
service until such time as the capability record is fully specified.
Then once we have the capability record fully specified the service
can simply be modified to return the correct document (and by then the
version number will be higher hence we can easily tell the difference).
In the meantime the mechanism will be in place and could be prototyped
and used in our ongoing implementations.

> What is the appropriate value of REQUEST for async requests that do
> not create the query?  The document indicates:
>    A TAP client must set this parameter correctly in every request
>    (GET or POST) to /async or /sync web resources.
> I take this as meaning that invoking something like
>   http://mytap/async/phase
> needs a REQUEST.  If it means something else it needs to be clarified.
>
> 2.3.2/2.8 The whole version and version negotiation framework seems complex 
> and ill defined.  E.g., what is the version of TAP that this document refers 
> to.  I'm guessing that it's '1.0' but perhaps it 'TAP 1.0' or whatever. 
> Specific examples of the strings to be used, especially the string that 
> specifies the current standard is required.  There's supposed to be some 
> sense of compatibility between versions x.a and a.b generally within the IVOA 
> framework, but how that is to apply here is not discussed.
>
> It is also unclear what a user is required to do.  E.g., can a data provider 
> simply ignore this parameter.  In 2.8.2 there is a statement that the service 
> 'declares the version it supports' but it's not clear to me how that is done.
>
> In 2.8.3 there is a phrase "does not match a version available from the 
> service at level two". I have no idea what this is.
>
> Overall I'd recommend -- especially since this is the first version of the 
> document -- that there should be a statement to the effect to the effect...
>
>   "Services must accept the VERSION parameter but may ignore it."

I don't think we want to start down the path of services supporting but
ignoring the VERSION parameter.  The main purpose of this parameter is
to provide strong checking against a runtime protocol version mismatch.
A secondary purpose is to allow selection of the version to be used
if the service implements multiple versions.  This mechanism was
adopted from minor changes from the OpenGIS standards, and is also
already used in SSA.

If the protocol version is explicitly specified by the client but
is a version not supported by the service this is a hard error and
the client gets an error response (if this is not what the client
wants it does not specify VERSION).  The value is supposed to be a
string such as "1.0".  It may well be that the details need further
clarification in the spec but the mechanism is fairly simple.

 	- Doug