Spectral Data Model V2.0 working draft

Wed Oct 17 01:34:00 PDT 2012

Hi Markus,

The document distributed to the working group is a working draft not
(yet) a proposed recommendation. This is why there is not a specific RFC
page yet. I think it is OK to send comments directly to the WG list for
the time being.

Thanks,
Jesus

On Wed, 2012-10-17 at 09:59 +0200, Markus Demleitner 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
> 
-- 
Jesus J. SALGADO                       Jesus.Salgado at sciops.esa.int

ESAC Science Archives Team
European Space Astronomy Centre (ESAC)
European Space Agency (ESA)

European Space Agency/European Space Astronomy Centre
P.O. Box 78
28691 Villanueva de la Canada                 Tel: +34 91 813 12 71
Madrid - SPAIN                                Fax: +34 91 813 13 08
-------------------------------------------------------------------

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.