[utypes] Versioning

[Markus Demleitner]

Dear utype enthusiasts,

On Tue, Feb 07, 2012 at 06:34:12PM -0500, Omar Laurino wrote:
> the single entity and use it for the entire namespace. At that point,
> though, we have two options: either we keep the namespace label (e.g. char)
> fixed and we add the versioning string to it (char-1.1) or we include a
> dynamic mechanism for namespace declaration, a la XML.

Ah -- let me re-iterate my reservations to the term "namespace" here.
The stuff in front of the colon is, as the current draft wisely
states, a data model name.

And I am quite sure we should not have versions in there.  The main
reason is that I strongly believe we should allow "best-effort"
interpretation of utype-encoded data models.  This means, in
particular, that we shouldn't wantonly obsolete applications that at
one point understood a data model, i.e., could do something with a
utype mod:a.b.c.  In all likelihood, even if the data model mod was
updated, whatever the application did will still be valid and should
not fail.  So, we should *not* have versions in the data model
prefix.

Granted, if a client actually needs to know the exact data model, it
should be able to figure that out.  Allow me to repeat what's
suggested in the STC-in-VOTable note:  There's the "reserved" package
name DataModel in each data model; in there there's an item URI
giving the data model URI (i.e., you can figure out the data model
URI by checking the value of the <modname>:DataModel.URI utype.

Given the new StandardsRegExt, I'd like to extend that and say in
each standard data model (and preferably for all others, too), there
should also be a utype <modname>:DataModel.ivoId containing the IVORN
of the standard.  That way, it would be easy to obtain a reference
URL for the data model, you could figure out who came up with the
standard, etc.

Cheers,

         Markus