Spectral 2.0 - Document update

[Markus Demleitner]

Hi Mark, hi DM,

On Thu, May 28, 2015 at 03:42:28PM -0400, CresitelloDittmar, Mark wrote:
> Except.. Marcus suggests in his feedback comments that the model
> prefix should change with each version of the model (so the
> spectral-2.0 model Utypes would use 'spec2' instead of 'spec').
> While I have been of the opinion that the prefix was fixed for that
> flavor of dataset, and the versioning info must come from the other
> model elements.

Just briefly on this: I believe, and that holds for future VO-DML
modelling, too, that only changes in the major version should be
reflected in the data model name (or "prefix" with legacy utypes).
So, if this were Spectrum 1.1, I agree it should still be spec:, and
that has worked fairly well in the comparable case of VODataService's
recommended namespace prefix; "no new major version" essentially
means "the utypes didn't change their meanings".

Now, since we're saying "This is version 2.0," i.e., a new major
version, we're implying that utype meanings (may) have changed
significantly, and applications believing they know what spec: means
should not be lured into trying to interpret these new utypes.  Hence
I'm convinced we essentially must adopt the rule: "new major versions
imply new namespace names."

> Change List:

While I've not gone into the doc thoroughly so far, let me nag again
for a media type to be defined here.  I claim that's not for any
access protocol (SSA, say) to define, as there could be multiple
relevant protocols (in my system, at least SSAP, Obscore, and
Datalink are concerned by SDM2); each must have the media type to let
applications understanding SDM2 figure out that datasets accessible
to them are available.  And just saying "it's a VOTable" is not good
enough, as that could be SDM1, or a future sanitised serialisation,
of just ad-hoc output of a DB query, or whatever.

Soo...  can't we just have this little passage:

  The RFC 2046 media type of spectral data model 2 instances
  serialized to VOTables is

    application/x-votable+xml;content=spec2.

  Where this media type is used in data discovery (e.g., the SSAP
  FORMAT parameter and Access.Format value, the obscore access_format
  column, or the datalink content_type column), data providers SHOULD
  use it literally as given here, i.e., without additional
  whitespace, changes in case, or additional parameters.
  Applications MAY assume this form.

  Outside of data discovery, applications must cope with additional
  parameters and media type syntax changes.  For instance, a file
  delivered by a service with a content-type header of

    application/x-votable+xml; content=spec2; serialization=binary2

  should be processed as an SDM2 instance.

in Appendix C?  It'd make interoperable use of this *much* easier.

Cheers,

       Markus