<div dir="ltr"><div dir="ltr">Markus,<div><br></div><div>I've added the order and relorder elements/UTypes to the document.</div><div>My understanding of their usage is that you would add one or two FIELDs to your table.</div><div>  o utype="spec:Spectrum.Data.SpectralAxis.order"</div><div>  o utype="spec:Spectrum.Data.SpectralAxis.relorder"</div><div>providing the order assignment(s) for each row of the table.</div><div><br></div><div>There shouldn't be any structural changes needed from this update.. it is supposed to be a very lightweight addition/change.</div><div><br></div><div>If you are asking if that example file is 'valid' per the spec, that's a bit harder.  I haven't done a thorough review of that file, but from a quick-ish scan.</div><div>The spec says in Section 8.2: </div><div class="gmail-page" title="Page 60" style="color:rgb(0,0,0)"><div class="gmail-layoutArea"><div class="gmail-column"><ol start="0" style="list-style-type:none"><li><p><span style="font-size:11pt;font-family:CMSS10">We use nested GROUP constructs to delimit data model objects within the main object, and PARAM and FIELD tags for attributes. The nesting beyond a single GROUP is optional, as for cases for which the utypes are unique within a group, the utypes can be used to infer the datamodel structure.</span></p></li></ol></div></div></div><div>From this, I gather that there should be a GROUP for each of the included nodes in Figure 2, with the exception of Spectrum.</div><div>Per the example, utype="spec:Spectrum" is assigned to the TABLE element.</div><div>So, your example is missing:</div><div>  o The utype on TABLE</div><div>  o GROUP utype="spec:Spectrum.Derived"<br></div><div>  o GROUP utype="spec:Spectrum.CoordSys"</div><div><div>  o GROUP utype="spec:Spectrum.Data"</div><br class="gmail-Apple-interchange-newline"></div><div>And at first glance, it looks like it has PARAMs with 'invalid' utypes</div><div>Those with a 'Dataset' node e.g. "spec:Spectrum.Dataset.DataModel"  should be  directly on Spectrum ("spec:Spectrum.DataModel")</div><div><br></div><div>Mark</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 25, 2022 at 3:42 AM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Mark,<br>
<br>
On Wed, Jul 20, 2022 at 04:29:46PM -0400, CresitelloDittmar, Mark wrote:<br>
> I think it captures the requested functionality.  I'm happy to take input<br>
> on how they are described.. I tried to pull from the discussions for that,<br>
> but may have gotten some detail wrong.<br>
<br>
At this point I'm mainly interested in using this to represent<br>
Echelle spectra as envisaged in<br>
<a href="https://github.com/ivoa-std/SpectrumDM/issues/2#issuecomment-1189166132" rel="noreferrer" target="_blank">https://github.com/ivoa-std/SpectrumDM/issues/2#issuecomment-1189166132</a><br>
<br>
Do you already see how one would do that?  In particular, am I<br>
already doing what you intend (modulo some utypes and UCDs) in my<br>
pseudo-SDM Echelle spectra, e.g.,<br>
<<a href="http://dc.zah.uni-heidelberg.de/getproduct/flashheros/data_raw/ca98/blue/n0393.mt" rel="noreferrer" target="_blank">http://dc.zah.uni-heidelberg.de/getproduct/flashheros/data_raw/ca98/blue/n0393.mt</a>>?<br>
<br>
If not, and structural changes are required: What would those be?<br>
<br>
Thanks,<br>
<br>
          Markus<br>
</blockquote></div></div>