VOTable 1.5 Working Draft (2023-09-13)

[Francois Ochsenbein]

Thank you Markus for this summary. I did notice the change in section 3.2
"name, ID and ref attributes" and imagined that the change in COOSYS was
the motivation ; you say it's an "unrelated issue" ; I'm just curious to
learn more about this issue ? And among the "alternative proposals" you
are quoting the "Aladin method" — does topcat use a different method ?

And anyway the section 7 should be updated to reflect the changes before
any recommendation. On the style I feel the suppression of space between
paragraphs (the \parskip) makes reading somewhat uncomfortable (in a
comparison between 1.4 and 1.5 versions).

Cheers, François

>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/769affb8/attachment.htm>