Difference: VOEventV21RFC (3 vs. 4)

VOEvent2.1 Proposed Recommendation: Request for Comments

Summary

VOEvent 2.1 defines the content and meaning of a standard information packet for representing, transmitting, publishing and archiving information about a transient celestial event, with the implication that timely follow-up is of interest. The objective is to motivate the observation of targets-of-opportunity, to drive robotic telescopes, to trigger archive searches, and to alert the community. VOEvent is focused on the reporting of photon events, but events mediated by disparate phenomena such as neutrinos, gravitational waves, and solar or atmospheric particle bursts may also be reported.

Proposed Recommendations (PRs) for VOEvent 2.1 can be found at:

• 2024-05-22: last PR

Changes since 2.0

This document describes an update to the IVOA VOEvent recommendation for the representation of solar system events. It has been developed by the Solar System and Time Domain Interest Groups. Details of changes from v2.0 are described in the document.

Reference Interoperable Implementations

Implementations Validators

Comments from the IVOA Community during RFC/TCG review period: 2024-09-15 - 2024-10-31

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments by MarkusDemleitner 2024-09-27

(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.

(2) Abstract: I consider it really odd to have something like a hyperself-citation ("\citep{2011ivoa.spec.0711S}") in the abstract, even more so in that cites an earlier version of the current standard. Unless I'm missing something big time, I'd strongly suggest to remove that citep.

(3) (Retracted)

(4) The section "Status of this Document" has a comment "to be removed". I'd second that, because you have a lot of nonstandard information in there that people used to ivoatex won't expect there; and you'll keep forgetting updating this because that's really ivoatex's turf, which has already added such a section right below the abstract. Just remove the section and re-distribute the material you think you still need somewhere else. I have taken the liberty to move the relationships to other standards to where it normally belongs in ivoatex documents.

(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.

(6) Sect. 2.1 cites the "IVOA VOEvent Transport Note". I can't be bothered to properly investigate, but I think that's basically what's now the "VOEvent Transport Protocol" REC. If so, let's cite that. By the way, commenting on that REC would be appropriate in the Role within the VO subsection, too, since it's in the role diagram.

(7) Sect. 2.2 still talks about IVORN-s, a term we have have given up in the registry as unhelpful, and the term "IVORN" is also baked into quite a few element names and other stuff we can't change without breaking things. So, I'd suggest to give a bit of a historical note and state that "IVORN" is a term specific to VOEvent and outside of it people should say IVOID. I'd happily contribute text like that. May I?

(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?

(9) Sect. 2.2 promises a VOEventStreamRegExt and a VOEventServerRegExt, and it claims the Registry could hold VOEvent instances. VOEventStreamRegExt now comes with the present document, while VOEventServerRegExt never materialised, and there is no place for VOEvent documents themselves in the Registry. Frankly, I would like to rewwrite that entire passage. May I?

(10) Sect. 3.1 "The version attribute is required to be present and to equal "2.0" for all VOEvent packets governed by this version of the standard." – I have no particular concern with that as such (I don't know why the minor version was included here, though), but I predict everyone will be confused unless you comment why something specified in a 2.1 spec would have 2.0 here. Or bump this to 2.1.

(11) Sect 3.1 "The xmlns attribute refers to one-or-more standard XML namespace declarations that may optionally help define the contents of a packet." – that's not all wrong but wrong enough that I'd prefer to drop it (and the xmlns in the example above). This is no place to discuss XML namespaces, but we shouldn't confuse people with cloudy statements either.

(12) Throughout: Don't use {\tt x} any more. It's a miracle that still works. Rather, do \texttt{x} or, perhaps better suited to code-like strings, \verb|x|. Ask me and I'll do a PR; I didn't want to spoil the diff for the minor fixes PR, else I'd already have done it.

(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".

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee

TCG Vote :

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.