TAP Implementation Issues (cont'd)

[Douglas Tody]

On Thu, 22 Oct 2009, Patrick Dowler wrote:

> On Thursday 22 October 2009 12:07:31 Doug Tody wrote:
>> My preference would be that a minor version number increase ("level
>> 2" or x.n+1) would indicate that the new interface is backwards
>> compatible.  That is, new functionality or detail has been added
>> but the older parts of the interface have not changed.  Hence if the
>> client requests version 1.1 and the service implements 1.2 that is ok.
>> If the client requests 1.2 but gets 1.1 that is an error as presumably
>> the client needs whatever was added in 1.2.
>
> This is consistent with my understanding as well: the major version has to
> match and the minor version of the request (eg the minor in the VERSION param)
> has to be equal to or less than the version supported by a service since minor
> version changes are backwards compatible: they only add features to the spec.
>
> Right now there is only one value (VERSION=1.0) for a client to use (also true
> of SSA) so implementation is easy and we don't have any (way to gain) real
> experience with how much of a pain it is in practice.

We adopted this from OpenGIS (both REQUEST and VERSION) which uses
it in things like their WMS service.  Hence while we might not have done
much with it yet in VO, we are adopting a mechanism which has already
been proven in this other, probably larger community.

I think a single VERSION entity is preferable to multiple params as it
keeps all the information in one place and is not hard for service code
to parse.

> It is probably good practice for clients to be explicit and always set the
> VERSION. In case of multiple major versions this makes the request
> unambiguous.

I agree, although few if any clients specify the version yet.
While specifying the version should be recommended we want to keep it
as optional to provide a simple way for the client to defeat protocol
version checking (the client or user may "know" that for the particular
usage being attempted the version difference does not matter, allowing
minor version mismatches to be overridden).

 	- Doug

> In the case of minor versions, they can make sure that the
> service is not going to ignore a parameter they are using that was added in a
> minor version upgrade (eg client sends a  VERSION=1.1&FOO=bar, where FOO is
> the new param; service understands version 1.0 only and correctly ignores FOO,
> but if the client says it is using 1.1 the service will correctly return an
> error rather than silently ignore FOO and return a potentially incorrect
> response).
>
> -- 
>
> Patrick Dowler
> Tel/Tél: (250) 363-0044
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9E 2M7
>
> Centre canadien de donnees astronomiques
> Conseil national de recherches Canada
> 5071, chemin West Saanich
> Victoria (C.-B.) V9E 2M7
>