<div dir="ltr"><br>Dear Markus,<br><br><br>>Dear François,<br>><br>>On Mon, Oct 16, 2023 at 09:05:50AM +0200, Francois Ochsenbein wrote:<br>>> VOTable is an important component in the VO, and I'm really not sure<br>>> it's worth to change the VOTable schema as proposed in section 3.4 —<br>>> and is it  <br>><br>>Well, it's a non-intrusive change that doesn't break anything, so I'd<br>>say the cost is very low indeed.<br><br>==> Sorry, but I disagree on this point: it IS intrusive because:<br>    "COOSYS element SHOULD also be used to group and label coordinates"<br>    while in the previous versions care was taken to avoid specific<br>    requirements about ucd or utypes — in other words keeping VOTable<br>    generic; it's up to applications to define such requirements. It is<br>    therefore, at least in my mind, a major change in the VOTable scope.<br><br>>> components should be placed ? Also don't forget that the COOSYS<br>>> element was up to now located at the RESOURCE level, and from there<br>>> you can't safely reference FIELDs which may exist in several TABLEs;<br>>> should COOSYS become as a sub-TABLE element? Could the example<br>>> proposed at the end of section 3.4 work is there are several TABLEs<br>>> in the RESOURCE ?  <br>><br>>Ah: is that the "safely" in you original mail?  Let me try to<br>>re-phrase it:<br>><br>>  If COOSYS contains references into a TABLE and that TABLE is<br>>  taken out when re-organising the VOTable, the references in the<br>>  COOSYS will be dangling.<br><br>==> It's worse that this: the referencing may quote FIELDs in different<br>    TABLEs, which potentially generates a complete mess!<br><br>>If that is your concern, it is a valid one, but, really, whenever you<br>>are manipulating a VOTable by adding or replacing TABLE-s, you have<br>>to check and re-do all references because, for starters, you may have<br>>colliding identifiers. When you do that the proposed COOSYS<br>>references would probably be your least concern.<br>><br>>The difficulties of maintaining referential integrity when writing or<br>>modifying VOTables are exactly why I am not so enthusiastic about<br>>your proposal of doing<br>><br>>  <GROUP ucd="pos" ref="coosys-reference">...<br>><br>>-- against having the references as children of COOSYS, it's just one<br>>extra reference that people need to maintain and work out.<br>><br>>But as I said: If people like the extra GROUP *that* much better than<br>>a slight extension of COOSYS, they are welcome to write an<br>>alternative specification (including "how *exactly* are clients know<br>>a GROUP is defining a set of coordinates) and then change the astropy<br>>pull request. Very frankly: I expect that these exercises will<br>>convince just about everyone that just extending COOSYS is the<br>>rational way to go.<br>><br>>But if not and the extra effort seems worth it, that's fine with me<br>>as well, and I will fix my server-side implementation to generate<br>>such GROUP-s.<br>><br>>It's just that *I* don't want to spend a lot of work on what I think<br>>incurs a significant complication for almost no benefit at all; I<br>>hope you can sympathise with that sentiment.<br>><br>>For reference:  François'<br>><br>>> <RESOURCE><br>>> <COOSYS ID="ICRS-geo" system="ICRS" refposition="geocenter" /><br>>> <COOSYS ID="ICRS-2016" system="ICRS" epoch="J2016.0"<br>>> refposition="barycenter" /><br>>> ...<br>>><br>>> <TABLE><br>>><br>>> <FIELD ID="col1" name="RA" ucd="pos.eq.ra" unit="deg"<br>>> ref="ICRS-2016"/> <FIELD ID="col2" name="Dec" ucd="pos.eq.dec"<br>>> unit="deg" ref="ICRS-2016"/> ...<br>>> <FIELD ID="col11" name="RA-predicted" ucd="pos.eq.ra" unit="deg"<br>>> ref="ICRS-geo"//><br>>> <FIELD ID="col12" name="Dec-predicted" ucd="pos.eq.dec" unit="deg"<br>>> ref="ICRS-geo"/><br>>> <FIELD ID="col13" name="Date" unit="yr" ucd="time.epoch" ><br>>> <FIELD ID="col14" name="AU" unit="au" ucd="pos.distance" ><br>>> ...<br>>><br>>> <GROUP name="astrometry-main" ucd="pos" ref="ICRS-2016"><br>>>   <DESCRIPTION>Components of the position at the mean<br>>> epoch</DESCRIPTION> <FIELDref ref="col1" utype="LonLatPoint-lon" /><br>>>   <FIELDref ref="col2" utype="LonLatPoint-lat" /><br>>>   ...<br>>> </GROUP><br>>><br>>> <GROUP name="astrometry-predicted" ucd="pos" ref="ICRS-geo"><br>>>   <DESCRIPTION>Individual geocentric computations at reported<br>>> dates</DESCRIPTION><br>>>   <FIELDref ref="col11" utype="LonLatPoint-lon" /><br>>>   <FIELDref ref="col12" utype="LonLatPoint-lat" /><br>>>   <FIELDref ref="col13" ucd="time.epoch" /><br>>>   <FIELDref ref="col14" ucd="pos.distance" /><br>>>   ...<br>>> </GROUP><br>>> ...<br>>> </TABLE><br>>> </RESOURCE>  <br>><br>>would simplify to<br>><br>>  <RESOURCE><br>>  <COOSYS ID="ICRS-geo" system="ICRS" refposition="geocenter"><br>>    <FIELDref ref="col1" utype="LonLatPoint-lon" /><br>>    <FIELDref ref="col2" utype="LonLatPoint-lat" /><br>>  </COODYS><br>>  <COOSYS ID="ICRS-2016" system="ICRS" epoch="J2016.0"<br>>  refposition="barycenter" ><br>>    <FIELDref ref="col11" utype="LonLatPoint-lon" /><br>>    <FIELDref ref="col12" utype="LonLatPoint-lat" /><br>>    <FIELDref ref="col13" ucd="time.epoch" /><br>>    <FIELDref ref="col14" ucd="pos.distance" /><br>>  </COOSYS><br>>  <TABLE><br>><br>>  <FIELD ID="col1" name="RA" ucd="pos.eq.ra" unit="deg"<br>> ref="ICRS-2016"/> <FIELD ID="col2" name="Dec" ucd="pos.eq.dec"<br>> unit="deg" ref="ICRS-2016"/> ...<br>>  <FIELD ID="col11" name="RA-predicted" ucd="pos.eq.ra" unit="deg"<br>>  ref="ICRS-geo"//><br>>  <FIELD ID="col12" name="Dec-predicted" ucd="pos.eq.dec" unit="deg"<br>>  ref="ICRS-geo"/><br>>  <FIELD ID="col13" name="Date" unit="yr" ucd="time.epoch" ><br>>  <FIELD ID="col14" name="AU" unit="au" ucd="pos.distance" ><br>>  ...<br>><br>>  </TABLE><br>>  </RESOURCE><br>><br>>(where I'd have to see some code exploiting FIELDrefs with ucds<br>>rather than utypes before I'd admit that's a good idea).  I think you<br>>can guess that in particular in parsing code, that's *a lot* easier<br>>to deal with.<br>><br><br>==> It looks like a joke, where is the simplification ? The change<br>    proposed in COOSYS is not robust, since references can only be<br>    placed BEFORE their definition, therefore forbidding a simple<br>    streaming processing; and the FIELDs required for a complete<br>    interpretation of the astrometry may concern other components<br>    not concerned a priori by the coordinate system, like time or<br>    wavelength. Putting those in a COOSYS envelope looks at least<br>    strange…<br><br>><br>>             Markus<br><br>Cheers, François<br></div>