Spectral Data Model V2.0 working draft

[Omar Laurino]

Hi,

I agree with Markus. This escaped our internal review, but should be easily
fixed. I don't think I agree that we shouldn't use the term namespace, but
that's a utypes issue. For what the DM serialization is concerned, the
utypes syntax doesn't have anything to do with the XML namespaces notation
(true even if utypes were not fixed strings).

Cheers,

Omar.

On Wed, Oct 17, 2012 at 9:59 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

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



-- 
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/dm/attachments/20121017/6b2b4962/attachment-0001.html>