[utypes] Versioning

[Omar Laurino]

Hi Markus,


> 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.
>
>
In the stuff I circulated Namespace refers to a class in the general Data
Modeling framework. The "stuff in front of the colon" is referred to as the
Namespace label in my email.



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


I am wondering whether you received the email in which I presented the
draft for use cases, requirements and offered an example of how my
suggestion would actually work: I explicitly showed how what you described
would work. For the most part it is equivalent to what you wrote.

In any case, let's call "The Thing" the stuff in front of the colon. My
question was whether The Thing should be universally defined for all the
instance documents or dynamically defined in the instance itself.

[Please note that in my suggestion the word namespace is used to refer to
an abstract container of unique concepts, so I guess the term namespace
applies in this case. At least, in C++ and XML it would be called namespace
and my use of the term namespace is consistent with the XML namespaces
specification. (http://www.w3.org/TR/REC-xml-names/)]

So, we should *not* have versions in the data model
> prefix.


Having one string in one place ("dm=char-1.0") is equivalent to having two
strings in two places ("dmname=char", "dmversion=1.0") and it requires the
knowledge of the same amount of incompressible information by the client,
when parsing the file. So I am happy with any solution that lets the client
know these two pieces of information. In either case, my question stands:
is The Thing universally defined (if yes, where? Is there a list of IVOA
Things somewhere?)



> 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.
>
>
You really want to require a 1-client-2-servers-2-stages operation for
getting the data model version? (ask for resolution of the URI, then
retrieve the file from the resolved URL and then get the information on the
version).

Note that in general the client application will know about several
versions up to a certain one. The client has to know whether the version
it's handling is older or newer than the ones he knows of.

In any case, for the Data Model specs retrieval I am in favor of a solution
that includes as much information as possible in the single instance. The
reason is that this doesn't involve network availability and dereferencing
pointers in a distributed architecture. This is not a functional
requirement, though. It is an architectural non-functional requirement and
both options are functionally equivalent. I guess in the end it is a
trade-off between self-consistency and compactness.

My suggestion was more focused on the reuse and extensibility of entities,
including versioning. It also tries to bridge the information gap between
objects representations in rich, structured formats like XML and flat,
unstructured tabular representations like VOTable and FITS.

You didn't comment much on this part, so I guess we can happily iron out
the non-functional details and get the document done.

Cheers,

Omar.

-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-376 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/utypes/attachments/20120208/b2eb9e43/attachment-0001.html>