<div dir="ltr"><div dir="ltr">This puts a twist in my brain that I'm having trouble straightening out.</div><div dir="ltr"><br><div>I interpret Markus' statement: <span style="color:rgb(80,0,80)">"shapes are serialised </span><span style="color:rgb(80,0,80)">in whatever way the container formats wants them; in VOTable, use</span><span style="color:rgb(80,0,80)"> PARAM-s to store literals".  </span>to mean that VOTable would define the serialization for each shape.. for example:</div></div><div class="gmail_quote gmail_quote_container"><div class="gmail_attr">   "A GROUP element containing FIELDref/PARAM/PARAMref elements for each attribute ( center_x, center_y, semi_major, semi_minor, angle )"</div><div class="gmail_attr">   This would <b>require</b> UCDs to identify each of the attributes since FIELDref does not contain names, and the column names probably won't match the attributes. (eg "RA" vs 'center_x' )</div><div class="gmail_attr"><br></div><div class="gmail_attr">Then there is the DALI serialization spec.. defines value list and order along with constraints that let the values be a simple list of numbers.  This is more restrictive than the GROUP representation.  I'm not too familiar with that form, but it seems like it would be something like </div><div class="gmail_attr">       <FIELD<span class="gmail-Apple-converted-space"> name="<colname>" xtype="ellipse</span>" datatype="double" arraysize=5 /><br></div><div class="gmail_attr"> where the column value resolves to fill the 5 attributes.</div><div class="gmail_attr"><br></div><div class="gmail_attr"><b>The goal here is for a Model to allow different representations of the Ellipse</b> (or whatever datatype) at different levels of normalization.  DALI may restrict to the DALI representation, but something more generic (like FOV/REGION) might want to allow a simple DALI string, STC-S string, MOC, or more full VOTable GROUP.  The provider could supply whichever satisfies the needs of their data.</div><div class="gmail_attr">THAT would require being able to identify which representation is being supplied, so the user knows how to interpet it.</div><div class="gmail_attr"><br></div><div class="gmail_attr">With the above paragraph, I'm thinking also of the Coordinates model to some degree.  This mechanism would allow a simple representation for the case of "Sky Coordinate in standard Reference position and reference Frame", while allowing for a fuller representation for others (e.g. "ccd coordinates").</div><div class="gmail_attr"><br></div><div class="gmail_attr">Mark</div><div class="gmail_attr"><br></div><div class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Wed, Mar 19, 2025 at 11:42 AM Patrick Dowler via dm <<a href="mailto:dm@ivoa.net">dm@ivoa.net</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">On Wed, 19 Mar 2025 at 06:01, Markus Demleitner via dm <<a href="mailto:dm@ivoa.net" target="_blank">dm@ivoa.net</a>> wrote:<br>
> So, I'd say DM should say not much more than "shapes are serialised<br>
> in whatever way the container formats wants them; in VOTable, use<br>
> PARAM-s to store literals".<br>
<br>
I agree with this. Serialization may differ depending on the format<br>
and DALI already<br>
says how to serialize in VOTable (sometimes referring to other<br>
standards like ISO8601<br>
or MOC when appropriate). That advice may or may not be applicable in<br>
other formats.<br>
<br>
--<br>
Patrick Dowler<br>
Canadian Astronomy Data Centre<br>
Victoria, BC, Canada<br>
</blockquote></div></div>