<div dir="ltr">Markus,<div><br></div><div>That is also my understanding. Thank you for summarizing it. And thanks to all the participants.</div><div><br></div><div>Adrian</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 16, 2023 at 8:07 AM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Dear François,<br>
<br>
First, for context a brief unofficial report-back from the telecon on<br>
the COOSYS issue:<br>
<br>
We discussed various alternative proposals, including<br>
<br>
* waiting for MIVOT+whatever models it will need<br>
* your intermediate groups<br>
* the "Aladin method" (my term), which is using @ref on the same<br>
COOSYS object and then assigning roles based on @utype or @ucd.<br>
<br>
The upshot was that I was asking for implementations (or at least,<br>
for the Aladin method, explicit rules). We'll see what's there in a<br>
small side meeting in Tucson; ideally, we'd see MIVOT-based epoch<br>
propagation, in which case this entire discussion is moot. If not,<br>
perhaps we can agree on some well-defined scheme (where I'm still<br>
hoping for a miracle for forward-referencing COOSYS:-). And if that<br>
doesn't come along, we'll drop forward-referencing COOSYS for VOTable<br>
1.5 so the other changes can go ahead.<br>
<br>
As I said, that's unofficial minutes, so if someone else wants to<br>
correct me, please do so.<br>
<br>
Meanwhile:<br>
<br>
On Mon, Oct 16, 2023 at 01:08:45PM +0200, Francois Ochsenbein wrote:<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>
Hm... I think that's a bit too philosophical for me, in particular<br>
because I feel the present proposal does nothing that's not plausibly<br>
intended by the current backward referencing. It just does so in a<br>
reliable way.<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>
But of course FIELD-s in different tables could also @ref the same<br>
COOSYS (and so could GROUP-s and so on), so I can't see how<br>
forward-referencing makes things worse than they already are (and I'm<br>
incidentally not sure how bad it would be to pick a PARAM from<br>
another table, say, but that's beside the point I'm making).<br>
<br>
This *would* of course matter if you could reference by name (rather<br>
than ID; I've asked for that in MIVOT, but I think it didn't happen),<br>
as then TABLE locality would apply -- you'd have my vote to enable<br>
that, but that *would* be a larger change.<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>
<br>
You'll see the simplification when you parse the two variations;<br>
in short, you're saving two ID/ref pairs, and you're making it dead<br>
simple to locate the annotation.<br>
<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>
<br>
Oh, we've largely given up on that in the metadata section (where<br>
streaming is of secondary importance because it's small). VOTable<br>
1.4 still says:<br>
<br>
From VOTable 1.2, it is further recommended to place the ID<br>
attribute prior to referencing it whenever possible.<br>
<br>
(but note that that's should-level). In 1.5 we say (because of an<br>
unrelated issue):<br>
<br>
The relative position of an ID and its corresponding reference(s)<br>
may have an impact on the performance or functionality of streaming<br>
parsers. For this reason, earlier versions of VOTable recommended<br>
placing the ID attribute before any references to it, but there may<br>
be cases where the opposite is more appropriate.<br>
<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>
Yeah, I wouldn't do that either, and it's not forseen by the current<br>
proposal. I just did it in order to not cheat by dropping markup<br>
from your example that may express extra semantics.<br>
<br>
Anyway, I think we have a plan forward; in the unlikely case everyone<br>
else declares their ok with the current draft in Tucson... would your<br>
concerns be strong enough to veto this?<br>
<br>
-- Markus<br>
</blockquote></div>