versions of resources and services

[Ray Plante]

Hi all,

We're reaching a point where a number of our standards are reaching
v1.0 Rec status; consequently, many have raised the issue of how we'll
deal with day when some services are v1.0 compliant and others, v1.1.
Cearly there's a job here for the registry.  We discussed this a bit in
Kyoto; however, there's certainly more thinking that needs to be done.

For now, I want to propose a level-zero solution based on what currently 
exists in the RM/VOResource metadata.  The schema defines two relevant
terms: Version and StandardID (which appear in VOResource as
curation/version and capability/@standardID).  

I recommend...

  o  Version should be used to describe the particular instance of a
     resource.  If it's a data collection, this might be the release
     version (as in DR1).  If it's a service--standard or otherwise--
     it would be the version of the implementation.  For example, if
     the implementation was changed to provide support for more
     parameters, then the provider might increase the version number.
     What warrents a change in this version value is up to the
     provider.  

  o  StandardID should be used to indicate the version of the standard
     that a service is compliant with.  The value of this metadatum is
     an IVOA identifier which should include version of the service
     standard, much like we do with our standard XML namespaces (e.g.,
     ivo://ivoa/std/ConeSearch/v1.0).  This metadatum would be used to
     indicate which version we are compliant with.

Using StandardID means that we need to set up a practice of
registering standards.  (This could be easily incorporated into our
IVOA registry of registries without impacting its role as a registry
or registries.)  I recommend that this only be done for standards that
have reached v1.0 status.  I think we also need to stick to the
convention of putting the version as the last field in the ID.  This
will make it easy not only to extract the version number, but to
identify service types that are the same apart from the version
number. 

Hopefully, this sounds reasonably straightforward, but it's probably
not the end of the story.  One question raised in Kyoto is whether we
should enable a service description to indicate it supports multiple
versions.  The above recommendation does not address this
possibility.  The registry data model tiger team work may shed some
light on this question.  

cheers,
Ray