VOTable 1.5 Working Draft (2023-09-13)

[Markus Demleitner]

Dear François,

First, for context a brief unofficial report-back from the telecon on
the COOSYS issue:

We discussed various alternative proposals, including

* waiting for MIVOT+whatever models it will need
* your intermediate groups
* the "Aladin method" (my term), which is using @ref on the same
  COOSYS object and then assigning roles based on @utype or @ucd.

The upshot was that I was asking for implementations (or at least,
for the Aladin method, explicit rules).  We'll see what's there in a
small side meeting in Tucson; ideally, we'd see MIVOT-based epoch
propagation, in which case this entire discussion is moot.  If not,
perhaps we can agree on some well-defined scheme (where I'm still
hoping for a miracle for forward-referencing COOSYS:-).  And if that
doesn't come along, we'll drop forward-referencing COOSYS for VOTable
1.5 so the other changes can go ahead.

As I said, that's unofficial minutes, so if someone else wants to
correct me, please do so.

Meanwhile:

On Mon, Oct 16, 2023 at 01:08:45PM +0200, Francois Ochsenbein wrote:
> ==> Sorry, but I disagree on this point: it IS intrusive because:
>     "COOSYS element SHOULD also be used to group and label coordinates"
>     while in the previous versions care was taken to avoid specific
>     requirements about ucd or utypes — in other words keeping VOTable
>     generic; it's up to applications to define such requirements. It is
>     therefore, at least in my mind, a major change in the VOTable scope.

Hm... I think that's a bit too philosophical for me, in particular
because I feel the present proposal does nothing that's not plausibly
intended by the current backward referencing.  It just does so in a
reliable way.

> >  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.
>
> ==> It's worse that this: the referencing may quote FIELDs in different
>     TABLEs, which potentially generates a complete mess!

But of course FIELD-s in different tables could also @ref the same
COOSYS (and so could GROUP-s and so on), so I can't see how
forward-referencing makes things worse than they already are (and I'm
incidentally not sure how bad it would be to pick a PARAM from
another table, say, but that's beside the point I'm making).

This *would* of course matter if you could reference by name (rather
than ID; I've asked for that in MIVOT, but I think it didn't happen),
as then TABLE locality would apply -- you'd have my vote to enable
that, but that *would* be a larger change.

> >(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.
> >
>
> ==> It looks like a joke, where is the simplification ? The change

You'll see the simplification when you parse the two variations;
in short, you're saving two ID/ref pairs, and you're making it dead
simple to locate the annotation.

>     proposed in COOSYS is not robust, since references can only be
>     placed BEFORE their definition, therefore forbidding a simple
>     streaming processing; and the FIELDs required for a complete

Oh, we've largely given up on that in the metadata section (where
streaming is of secondary importance because it's small).  VOTable
1.4 still says:

  From VOTable 1.2, it is further recommended to place the ID
  attribute prior to referencing it whenever possible.

(but note that that's should-level).  In 1.5 we say (because of an
unrelated issue):

  The relative position of an ID and its corresponding reference(s)
  may have an impact on the performance or functionality of streaming
  parsers. For this reason, earlier versions of VOTable recommended
  placing the ID attribute before any references to it, but there may
  be cases where the opposite is more appropriate.

>     not concerned a priori by the coordinate system, like time or
>     wavelength. Putting those in a COOSYS envelope looks at least
>     strange…

Yeah, I wouldn't do that either, and it's not forseen by the current
proposal.  I just did it in order to not cheat by dropping markup
from your example that may express extra semantics.

Anyway, I think we have a plan forward; in the unlikely case everyone
else declares their ok with the current draft in Tucson... would your
concerns be strong enough to veto this?

           -- Markus