Spectral 2.0 - Document update

[Markus Demleitner]

Dear Mark, dear List,

On Fri, Jun 05, 2015 at 10:31:15AM -0400, CresitelloDittmar, Mark wrote:
> There is another interpretation item I'd like to discuss w.r.t. Marcus'
> serialization.
> 
> The file contains some groups with PARAMrefs, but not all groups,
> and not all PARAMS have associated PARAMrefs.

The rationale behind having PARAMrefs rather than actual PARAMs in
the group was that the PARAMs themselves are mostly generated from an
SSA table, which has no grouping; I wanted to get the additional
annotation ("these things belong together") with little extra effort,
and the GROUP/*ref approach was already there from STC annotation.

> So we have this (snipped for brevity):
> 
>         <TABLE name="aesaiihe" utype="spec:Spectrum">
>             <GROUP utype="spec:Char">
>                 <PARAMref ref="asisbgoe"
> utype="spec:Char.TimeAxis.Coverage.Bounds.Extent"/>
>                 <PARAMref ref="aemlgmue"
> utype="spec:Char.SpectralAxis.Coverage.Bounds.Extent"/>
>             </GROUP>
> 
>             <PARAM ID="asisbgoe" datatype="float" name="ssa_timeExt"
> ucd="time.duration" unit="s"
>                    utype="spec:Char.TimeAxis.Coverage.Bounds.Extent"
> value="">
>             </PARAM>
>             <PARAM ID="aemlgmue" datatype="float" name="ssa_specext"
> ucd="em.wl;instr.bandwidth" unit="m"
>                    utype="spec:Char.SpectralAxis.Coverage.Bounds.Extent"
> value="2.8137e-07">
>             </PARAM>
>         </TABLE>
> 
> So, inside the Char group, there is a reference to define the
> TimeAxis.Coverage.Bounds.Extent
> And outside the groupings is a full PARAM with the same UType.
> 
> Presumably, the intent is that the PARAM is the same element as the
> PARAMref.  However, since

The intent was to just provide extra annotation to what was already
there; absent a proper metamodel it's hard to even say exactly what
that means.  Given the somewhat cloudy semantics of GROUP in the ad-hoc
SDM serialisation, I hadn't actually expected that software would use
GROUPs to create objects, in particular because they're optional and
once client software starts to look at them it needs to somehow merge
structures inferred by utypes and structure inferred by groups --
Mark's troubles here are just the beginning of where that leads to.

> It seems that, by convention, the use of PARAMrefs in Group should
> be limited to specifiying only DIFFERENT instances of an element.

This might be one possible answer; I think some language like this
would need to go into the document, but I'm not quite sure how it
would look like so people actually undestand what we mean.

But I'd like to submit again that it would be so much more economical
to just adopt VO-DML and use their VOTable mapping.  It is being
built *exactly* for cases like this.  Had we screapped the
SDM1-evolved "example serialisation" a year ago, we wouldn't have
this particular discussion now.  And we wouldn't try to piece
together a partial, incompatible version of DM-in-VOTable.  

I'd be happy to lend all the hands I can spare on creating the VO-DML
serialisation -- it could be done in days, I believe, if there's
already VO-DML for SDM (which I believe there is).

Cheers,

        Markus