<div dir="ltr"><br>Thank you Markus for this summary. I did notice the change in section 3.2<br>"name, ID and ref attributes" and imagined that the change in COOSYS was<br>the motivation ; you say it's an "unrelated issue" ; I'm just curious to<br>learn more about this issue ? And among the "alternative proposals" you<br>are quoting the "Aladin method" — does topcat use a different method ?<br><br>And anyway the section 7 should be updated to reflect the changes before<br>any recommendation. On the style I feel the suppression of space between<br>paragraphs (the \parskip) makes reading somewhat uncomfortable (in a<br>comparison between 1.4 and 1.5 versions).<br><br>Cheers, François<br><br>>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<br>>> coordinates" while in the previous versions care was taken to avoid<br>>> specific requirements about ucd or utypes — in other words keeping<br>>> VOTable generic; it's up to applications to define such<br>>> requirements. It is therefore, at least in my mind, a major change<br>>> 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<br>>> different 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<br>>> >you can guess that in particular in parsing code, that's *a lot*<br>>> >easier 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><br><br>-- <br></div>