VOTable 1.5 Working Draft (2023-09-13)

[Adrian Damian]

Markus,

That is also my understanding. Thank you for summarizing it. And thanks to
all the participants.

Adrian

On Mon, Oct 16, 2023 at 8:07 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20231016/8548d762/attachment-0001.htm>