TAP Implementation Issues (cont'd)

[Patrick Dowler]

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. 

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. 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