From msdemlei at ari.uni-heidelberg.de  Fri Sep 27 17:16:55 2024
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Fri, 27 Sep 2024 17:16:55 +0200
Subject: VOEvent 2.1 RFC
Message-ID: <20240927151655.jswqqxkexcg5hz5s@victor>

Dear TDIG,

You have probably seen it on the interop list: There's an RFC for
VOEvent 2.1 going on at
<https://wiki.ivoa.net/twiki/bin/view/IVOA/VOEventV21RFC>.  I have
just put in some review comments on that page, most of which are
probably only relevant of the editors.

However, a few points perhaps concern more people -- the
following are the points that I suspect are of that class:

(1) My main concern here is reference implementations. Do we have
active VOEvent streams? To me, this is particularly relevant with
respect to the registry part, where I have tried fairly hard to
register a VOEvent stream so people can try the discovery queries but
failed to do so. I'd actually be fairly unhappy if this went to RFC
without an actual resource in the Registry.

(5) "IVOA?s Space-Time Coordinate (STC) metadata specification (Rots,
2007). Some of the VOEvent structure is provided by this document"
This perhaps can't be done for this round of the document, but for
the next one I'd strongly advocate picking some subset of STC and
describing it in this spec (or do something completely different).
STC 1.30 itself is just too much to grok as a dependency of this
standard, and it's been superseded anyway.

(8) Sect 2.2 still abuses the fragment identifier when building the
IVOIDs of the Events. You see, ivo://authorityID/resourceKey#local_ID
implies that when you resolve and retrieve
ivo://authorityID/resourceKey, the resulting document will have a
part identified as (e.g., through an id attribute in XML) local_ID.
That is simply not the case here. Hence, it would be a lot better if
we used a ? here, implying "use a service on that the identifier (sc.
without the query part) identifies". Years ago I was told that would
break a lot of software. This little wart is probably not worth that.
But if that software is decommissioned now, perhaps this is the time
to fix this problem?

(13) 3.3.1.5 "it may return zero or NaN, but no exception should be
thrown." -- I think allowing a zero here is an exceptionally bad
idea. Does anyone remember why that was allowed? Anyway, I'd suggest
doing a "lightly-breaking" change here (meaning: it's still minor)
and saying "if it doesn't parse, it's a NaN. If you can't produce
NaNs, then bail out".

(14) 3.3.3 "the number of elements in each row should be the same as
the number of elements" -- does anyone remember why this was written
in this way? You see, I think this should have been a MUST, and if
it's just a should we'd need to say what clients are supposed to do
when there are too many or to few TDs. Perhaps we can use this
opportunity to sneak in a MUST? To me, that would still be
"lightly-breaking", i.e., ok for a minor version.

(15) 3.6 "pending a standard VO ontology or formal UCD-like
vocabulary of astronomical concepts" -- can anyone give an assessment
of what the UAT is missing to qualify? Ditto in 3.6.3. If you do
chose to somehow recommend or adopt the UAT here, the thing to
reference within the VO is 2022ivoa.spec.0722D.

If you have input to any of these points, I'm sure you will find
interested readers on this list.

Thanks,

             Markus