Spectral Data Model V2.0 working draft

[Markus Demleitner]

Hi,

On Tue, Oct 16, 2012 at 04:40:01PM -0400, Mark Cresitello-Dittmar wrote:
> A working draft of the Spectral DM V2.0 is available from the IVOA
> documents page:
> http://www.ivoa.net/Documents
> 
> Or more directly via:
> http://www.ivoa.net/Documents/SpectralDM/20120907/WD-SpectralDM-2.0-20120907.pdf
> 
> 
> This draft initiates a four weeks period of comments within the
> working group.
> Comments will be greatly appreciated.

I've not seen an RFC page of this on the wiki, so I'm blathering out
here -- I'm worried about the VOTable example serialization,
speficially 

xmlns:spec="http://www.ivoa.net/xml/Spectral/Spectral-2.0.xsd"

in the opening VOTABLE tag.  *Please* don't do this any more.  Utypes are
almost certainly supposed to be fixed strings, i.e., you can't just say

xmlns:ns1="http://www.ivoa.net/xml/Spectral/Spectral-2.0.xsd"

and expect ns1:Data.FluxAxis.Value" to work.  However, this must be
possible for XML namespace prefix bindings.  I personally am sure we
want Utypes to be fixed, so you can't use namespace prefix bindings.

This kind of thing blew up once before, when StandardsRegExt used the
ssa prefix as a "recommended" prefix for its SSA registry extension.
VOResource strongly recommends fixed prefixes (in this case there's
actually a rationale for this).  If you now wanted to declare the SSA
parameters using their utypes -- which also required an ssa prefix --
you would have had to constantly rebind the ssa prefix.

This uglyness is even worse since for Utypes, there not even a
rationale for binding *any* namespace prefix; VOTable utype
attributes aren't QNames, i.e., a sensible XML processor will
simply optimize away that gratuitous prefix declaration in the first
place, so their clients will have to employ serious magic to get to
it.

In short: It's abuse, it has always been abuse, and don't tell me you
can't change it any more because it's been in use for years.  It
hasn't, it's been a mess for years; see, e.g.,
http://docs.g-vo.org/talks/2012-urbana-ssapstate.pdf (tl;dr: a client
relying on any NS bindings would fail on at least 90% for the VO SSA
services) -- so dropping the bogus namespace declaration will
certainly not pose interoperability problems.

If you absolutely want to include a URL for the XSD, why not change
the existing

<GROUP name="Dataset">
  <PARAM name="DataModel"
    datatype="char" utype="spec:Dataset.DataModel" value="Spectrum-2.0" arraysize="*">
    <DESCRIPTION>Datamodel name and version</DESCRIPTION>
  </PARAM>
</GROUP>

to

<GROUP name="Dataset">
  <PARAM name="DataModel"
    datatype="char" utype="spec:Dataset.DataModel" value="Spectrum-2.0" arraysize="*">
    <DESCRIPTION>Datamodel name and version</DESCRIPTION>
  </PARAM>
  <PARAM name="DMXSD"
    datatype="char" utype="spec:Dataset.DataModel.XMLSchemaURL" 
    value="http://www.ivoa.net/xml/Spectral/Spectral-2.0.xsd" arraysize="*">
    <DESCRIPTION>XML Schema file related to the datamodel</DESCRIPTION>
  </PARAM>
</GROUP>

Also, the schema location definition for the
http://www.ivoa.net/xml/Spectral/Spectral-2.0 name space in the
example is of course gratuitous; nothing from that namespace is used
in the document, it's not even bound to a prefix (which might be a
typo, of course, but I suspect that typo went unnoticed because
nobody evaluates the xmlns binding).


In the same vein, I think that talking about "Namespaces" in 5.1.1 is
at least misleading.  Since this is a subsection of a chapter on
utypes, I believe "Namespace" here refers to the "thing before the
colon" in utypes, which would, at worst, be a namespace *prefix* (but
isn't, because utypes are not QNames, which is good since, as pointed
out above, namespace prefixes cannot really required to be fixed).

I guess this section can be rather simply fixed by replacing all
occurrences of "Namespace" with "model name".  In the opening
sentence you could add 'In the following, the term "model name"
refers to the part of a utype before the colon'.  (For the record,
I'm not saying that the mechanism proposed will be terribly helpful,
but since a working utypes spec is some time in the future I'm not
asking you to wait for better solutions).

If you absolutely detest the term "model name" (I give you the term
is being used elsewhere in the document with a different meaning; on
the other hand, the utypes draft has been talking about this thing as
DM name for quite a while), maybe DM shortcut would be an attractive
alternative.  Or maybe DM name prefix, although that dangerously close
to namespace prefix.

Sorry for the rant, but this kind of abuse has bitten me once too
often.

Cheers,

           Markus