VOTable 1.5 Working Draft (2023-09-13)

[Markus Demleitner]

Dear François,

On Tue, Oct 03, 2023 at 04:00:12PM +0200, Francois Ochsenbein wrote:
> Dear Markus,
> >On Wed, Sep 27, 2023 at 03:56:56PM +0200, Francois Ochsenbein wrote:
> >Um... I don't think I understand that point.  If this is advocating
> >the old "backward referencing" use of FIELD/@ref: the reason we have
> >been struggling with COOSYS all these years and still can't reliably
> >do automatic epoch propagation is exactly that FIELD/@ref is
> >insufficient in several ways:
>
> Well, the "old backward referencing" is safe, in the sense that you
> can't generate a contradiction, which is fundamental if you want to
> ensure the reliability in the description of your data. Accepting both
> ways of referencing is opening the door for contradictions…

I am not sure I understand which contradictions you are worried about
here -- could you perhaps give an example of a mistake that is more
likely with forward than with backward referencing?

Having said that, I am certainly not fond of referencing in both
directions; that's actually a huge pain.  If it was only me, I'd
deprecate @ref-ing COOSYS-es any day; but regrettably ref-less FIELDs
have semantics in the current VOTable spec.  We probably should at
least un-define that in 1.5, but we can't do away with backward
references all in one go.


> >* Implementational inconvenience: you have to change FIELDs to
> >  express metadata external to the FIELD itself, which makes for
> >  complicated and fragile code when writing VOTables.  With forward
> >  referencing, the metadata resides in isolated blocks that you can
> >  add easily as soon as the FIELD-s have an @ID.
>
> Here I don't understand what you mean — which change do you need?

Producing FIELDs from, say, database columns is something very
generic, that, at least in DaCHS, is done by a very generic
component.  DM-specific metadata, be it STC or perhaps photometry, is
handled by different code that runs quite a bit later.

It's great if these extra DM-aware components do not have to touch
the FIELDs generated by the generic component, that is, if the extra
annotation is self-contained.  Having to fiddle in ref attributes
into the FIELDs produced by the generic component is not pretty, and
it gets uglier if the various DM-implementing components have to
compete for the single ref attribute.

> ><https://github.com/ivoa-std/VOTable/pull/40#issuecomment-1719256399>:
> >If someone else writes that code for the client side, I'll do it on
> >the server side; but I suspect if you try to write such code, you
> >will find it's a complication that's probably simply not worth it.
>
> That's exactly the discussion I was referring to, this change is a
> transformation of COOSYS into a specialized GROUP. But I can't
> understand why the code would be more complex if you have the
> relationship referenced in a GROUP rather than in a COOSYS playing
> the GROUP's role ?

For the writer: You have to manage still another id-ref relationship,
with all the usual uglyness: Come up with an id, make sure it's
document-unique, make sure it stays that way when you merge VOTables,
and so on.

For the reader: You have to locate the group(s) that happen to link
COOSYS and the other elements (i.e., tell it from all kinds of other
groups that may be in a VOTable), and then follow the id-ref
relationship to the COOSYS the writer had to worry about in the first
place, handling all the possible errors that may happen (no element
with that ID, the element isn't a COOSYS, etc).

Yes, that's not rocket science, but it's not entirely trivial code
either, with many error conditions and corner cases to catch.  *If*
we actually improved matters by doing this, I might be willing to
write that code.  But at this point I still don't see a practical
problem that introducing this intermediate GROUP would fix.  Perhaps
if you tried again to explain the danger you perceive with forward
referencing?

> I'm also concerned by the vocabulary proposed in the section 3.4 —
> assigning the same utype name to a parallax and a distance seems
> inconsistent, and is a potential source for large errors, as was
> discussed following Mark Taylor's remarks.

As I said in my response to Mark: If the units are wrong, everything
is broken no matter what; creating more opportunities for
inconsistent annotation (e.g., a parallax-utyped FIELDref pointing to
a FIELD in pc) will probably not change that.

Having said that, I was trying to follow what I read from the Coords
DM (or Meas, for that matter).  If what I read is wrong, or if I was
filling holes that aren't there, I'm happy to change labels or
concepts.  As I said, ideally this is nothing but a bridge into
MIVOT+Coords+Meas to get people hooked without scaring them with a
metric ton of boxes-and-arrows.

So... if the DM folks say "rather use these-or-these concepts (and
perhaps that label here) and you'll have better compatibility with
MCT", I'll happily update them.

              -- Markus