VO-DML deployment

[Markus Demleitner]

Dear DMers,

In the context of the registration of data models, I spent a bit of
time thinking about how VO-DML URIs should be managed so versioning
"just works" while evolution remains naturally traceable.

What I've come up with is included below. I think this could be a
subsection before the registry topic proper; alternatively, it could
be somewhere close to the start of the document. There, the DM URI is
not formally introduced so far as far as I can see.  The first real
indication that DMs have a URI indentifying them appears to be the
Model.previousVersion, so it might be a good idea to make that a bit
more explicit anyway.

So, here's the prose I've drafted:

---------------------------- 8< ------------------------------
X.Y Deploying VO-DML models

To make VO-DML models usable, the model file needs to publicly
available.  In order to ensure correct versioning semantics, the
following constraints MUST be observed when publishing a VO-DML model:

(a) the model URI MUST contain the major version of the model

(b) the model URI MUST NOT contain the minor version of the model

(c) resolving the model URI MUST, possibly after redirects, lead to
the VO-DML for the latest minor version

(d) resolving the model URI SHOULD result in an HTTP redirect to a
URI that can be used to retrieve latest minor version of the VO-DML
model; model providers SHOULD make sure that the URIs returned in this
way remain stable for as long as possible so clients can, in principle,
retrieve prior versions of the documents.

For instance, the DM URI of the model defined in section Z.Z is
http://ivoa.net/xml/ivoa/ivoa-v1.vo-dml.xml [TODO: or whatever -- make
up a "best-practice" naming scheme as you want; I recommend a
one-directory-per-DM scheme, though].  This will remain constant for all
versions of the ivoa DM of the 1.0 series.

When retrieving http://ivoa.net/xml/ivoa/ivoa-v1.vo-dml.xml, the server
returns a document with an HTTP status code 303, redirecting (at the
time of writing) to http://ivoa.net/xml/ivoa/ivoa-v1.0.vo-dml.xml.  The
form of this second URL is not constrained by this specification, but
obviously names containing the minor version explicitly are highly
recommended.  

If the ivoa model is evolved, the redirect would end up at, say,
http://ivoa.net/xml/ivoa/ivoa-v1.1.vo-dml.xml.  Clients that have for
some reason cached the 1.0 URL could, however, keep on using it.

Technical note: One way to implement this scheme using the popular HTTP
server apache is to maintain an .htaccess file in the directory
containing the various versions and follow a pattern like:

  # sample .htaccess file for serving VO-DML
  #
  # This redirects the major version (the model URI) to the configured
  # (should be latest) minor version XSD file

  RewriteEngine On
  RewriteBase /ivoa/

  RewriteRule ^ivoa-v1.vo-dml.xml$ ivoa-v1.0.vo-dml.xml [R=303]
---------------------------- >8 ------------------------------

The technical note may not be necessary.  But it shows how I've
concocted an example deployment:

On http://docs.g-vo.org/ivoa/ you could see all minor versions that
there were (right now, there's just one).

But on retrieving http://docs.g-vo.org/ivoa/ivoa-v1.vo-dml.xml,
you'll get a redirect to the actual file, and that redirect would
always point to the latest v1 file (compare curl and curl -L for that
URL).

With this scheme and the HTML-doc URL in the VO-DML model declaration
(which would be another fixme), I think all aspects of a model would
be discoverable based on the VO-DML URI in a way compatible with IVOA
versioning rules.

Opinions?

         -- Markus