TAP Implementation Issues (cont'd)

[Doug Tody]

On Thu, 22 Oct 2009, Tom McGlynn wrote:

> One thing that my typo's may have obscured is the issue of upward
> compatibility.  There has been a general IVOA statement that version
> 1.n+1 in somehow compatible with version 1.n.  If I have a client that
> is requesting 1.1 but the service only supports 1.2 is that OK?  Or
> vice versa?  If no to both, then what do we mean by compatibility between 
> minor version numbers?  Or are we simply ignoring that precept here?
>
> Regardless the specification does not indicate how a service indicates
> which version it supports and I still have no idea what "level two" is.
> Are there any SSA services that actually do anything with this or is it 
> something that seems like a good idea but nobodies actually using?

While this has been addressed somewhat within IVOA (most recently
witin the documents and standards area I think) I am not sure we have a
sufficient definition yet of major/minor versions and how to deal with
finer points such as backwards compatibility.  SSA took a stab at this
but it is something which really needs a broader treatment within IVOA.

What I think we have so far is that a major version number increase
("level 1") e.g., 1.0 to 2.0, indicates that the interfaces are not
compatible; if the client asks for V2 and the service only does V1
then it is a protocol mismatch and a hard error.

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.

If the client does not specify the interface version then the service
would default to the highest "standard" version (hopefully the client
does some other checks or did a proper service selection in advance
using the version information in the registry, but that is not our
concern here).  "Highest standard version" seems obvious but the
issue is if the service supports a newer prototype version as well.
So for example the most recent standard version is 2.0 but the
service also provides a prototype of 2.1.  Then the client would get
2.0 by default but it could get 2.1 if it explicitly requested it.
The client is allowed to omit VERSION to disable runtime version
checking or explicit selection.

This is what I would suggest and what we have been doing with VERSION
in the DAL interfaces, but I am not sure if it agrees with the
latest discussions in other areas such as documents and standards.
Probably, although I am not sure the finer points have yet been
adequately addressed.

None of this has been used in earnest yet as so far we have few cases
where multiple protocol versions coexist.  In most cases thus far,
e.g., for SSA, what we have differs so much that these are considered
separate service types.

 	- Doug