VOTable 1.5 Working Draft (2023-09-13)

[Markus Demleitner]

Dear François,

On Mon, Oct 16, 2023 at 09:05:50AM +0200, Francois Ochsenbein wrote:
> VOTable is an important component in the VO, and I'm really not sure it's
> worth to change the VOTable schema as proposed in section 3.4 — and is it

Well, it's a non-intrusive change that doesn't break anything, so I'd
say the cost is very low indeed.

> components should be placed ? Also don't forget that the COOSYS element was
> up to now located at the RESOURCE level, and from there you can't safely
> reference FIELDs which may exist in several TABLEs; should COOSYS become as
> a sub-TABLE element? Could the example proposed at the end of section 3.4
> work is there are several TABLEs in the RESOURCE ?

Ah: is that the "safely" in you original mail?  Let me try to
re-phrase it:

  If COOSYS contains references into a TABLE and that TABLE is
  taken out when re-organising the VOTable, the references in the
  COOSYS will be dangling.

If that is your concern, it is a valid one, but, really, whenever you
are manipulating a VOTable by adding or replacing TABLE-s, you have
to check and re-do all references because, for starters, you may have
colliding identifiers. When you do that the proposed COOSYS
references would probably be your least concern.

The difficulties of maintaining referential integrity when writing or
modifying VOTables are exactly why I am not so enthusiastic about
your proposal of doing

  <GROUP ucd="pos" ref="coosys-reference">...

-- against having the references as children of COOSYS, it's just one
extra reference that people need to maintain and work out.

But as I said: If people like the extra GROUP *that* much better than
a slight extension of COOSYS, they are welcome to write an
alternative specification (including "how *exactly* are clients know
a GROUP is defining a set of coordinates) and then change the astropy
pull request. Very frankly: I expect that these exercises will
convince just about everyone that just extending COOSYS is the
rational way to go.

But if not and the extra effort seems worth it, that's fine with me
as well, and I will fix my server-side implementation to generate
such GROUP-s.

It's just that *I* don't want to spend a lot of work on what I think
incurs a significant complication for almost no benefit at all; I
hope you can sympathise with that sentiment.

For reference:  François'

> <RESOURCE>
> <COOSYS ID="ICRS-geo" system="ICRS" refposition="geocenter" />
> <COOSYS ID="ICRS-2016" system="ICRS" epoch="J2016.0"
> refposition="barycenter" />
> ...
>
> <TABLE>
>
> <FIELD ID="col1" name="RA" ucd="pos.eq.ra" unit="deg" ref="ICRS-2016"/>
> <FIELD ID="col2" name="Dec" ucd="pos.eq.dec" unit="deg" ref="ICRS-2016"/>
> ...
> <FIELD ID="col11" name="RA-predicted" ucd="pos.eq.ra" unit="deg"
> ref="ICRS-geo"//>
> <FIELD ID="col12" name="Dec-predicted" ucd="pos.eq.dec" unit="deg"
> ref="ICRS-geo"/>
> <FIELD ID="col13" name="Date" unit="yr" ucd="time.epoch" >
> <FIELD ID="col14" name="AU" unit="au" ucd="pos.distance" >
> ...
>
> <GROUP name="astrometry-main" ucd="pos" ref="ICRS-2016">
>   <DESCRIPTION>Components of the position at the mean epoch</DESCRIPTION>
>   <FIELDref ref="col1" utype="LonLatPoint-lon" />
>   <FIELDref ref="col2" utype="LonLatPoint-lat" />
>   ...
> </GROUP>
>
> <GROUP name="astrometry-predicted" ucd="pos" ref="ICRS-geo">
>   <DESCRIPTION>Individual geocentric computations at reported
> dates</DESCRIPTION>
>   <FIELDref ref="col11" utype="LonLatPoint-lon" />
>   <FIELDref ref="col12" utype="LonLatPoint-lat" />
>   <FIELDref ref="col13" ucd="time.epoch" />
>   <FIELDref ref="col14" ucd="pos.distance" />
>   ...
> </GROUP>
> ...
> </TABLE>
> </RESOURCE>

would simplify to

  <RESOURCE>
  <COOSYS ID="ICRS-geo" system="ICRS" refposition="geocenter">
    <FIELDref ref="col1" utype="LonLatPoint-lon" />
    <FIELDref ref="col2" utype="LonLatPoint-lat" />
  </COODYS>
  <COOSYS ID="ICRS-2016" system="ICRS" epoch="J2016.0"
  refposition="barycenter" >
    <FIELDref ref="col11" utype="LonLatPoint-lon" />
    <FIELDref ref="col12" utype="LonLatPoint-lat" />
    <FIELDref ref="col13" ucd="time.epoch" />
    <FIELDref ref="col14" ucd="pos.distance" />
  </COOSYS>
  <TABLE>

  <FIELD ID="col1" name="RA" ucd="pos.eq.ra" unit="deg" ref="ICRS-2016"/>
  <FIELD ID="col2" name="Dec" ucd="pos.eq.dec" unit="deg" ref="ICRS-2016"/>
  ...
  <FIELD ID="col11" name="RA-predicted" ucd="pos.eq.ra" unit="deg"
  ref="ICRS-geo"//>
  <FIELD ID="col12" name="Dec-predicted" ucd="pos.eq.dec" unit="deg"
  ref="ICRS-geo"/>
  <FIELD ID="col13" name="Date" unit="yr" ucd="time.epoch" >
  <FIELD ID="col14" name="AU" unit="au" ucd="pos.distance" >
  ...

  </TABLE>
  </RESOURCE>

(where I'd have to see some code exploiting FIELDrefs with ucds
rather than utypes before I'd admit that's a good idea).  I think you
can guess that in particular in parsing code, that's *a lot* easier
to deal with.

Thanks,

             Markus