VOEvent registration: Ha!

[Markus Demleitner]

Dear TD IG,

Thanks to the great people from CHIME, I now have the "reference
implementation" for a VOEvent registration that I've wanted to make
at least since VOEvent commit c00365a1 (2020-05-06, almost four years
ago): It's ivo://org.gavo.dc/std/chime-frb/chime-frb [1].

So, this would be the ideal time for people who know VTP and
subscribing to VOEvent streams to see whether you can figure out what
sect. 4.2 of the current VOEvent PR says and whether you succeed in
the use case "subscribe to all registered and open VOEvent streams"
-- and if not, what is missing.  I would *dearly* love for that
experiment to have been made before VOEvent 2.1 goes to REC and we
can't fix it any more.

During this exercise, I had three, umm, issues; perhaps someone here
wants to comment on them, too:

* Many VOEvent streams will be of the "continuously updated" type.
  The Registry currently doesn't really have a way to express that,
  although the requirement has come up before in other circumstances.
  I've long thought that this would be most easily reflected by
  setting a curation/date[@role="utpdated"] in the reasonable future
  (i.e., ~plausible project lifetime).  I've done this for the chime
  resource.  Does anyone see anything where that sort of shortcut
  will hurt us later?

* The record has a stream capability and an archive capability
  (the latter is just a WebBrowser thing here, but I imagine this
  could be a TAP service later).  At this point, the fact that that's
  an archive is not machine readable.  Defining this without a
  VOResource extension doesn't seem straightforward either:
  Capabilities don't have a role attribute or something like it.  We
  could define a standardID, possibly
  ivo://ivoa.net/std/voevent#browser-archive (then then later perhaps
  #tap-archive), but somehow this doesn't feel quite right, in
  particular because "browser-archive" sort of is the opposite to
  "standard".  Hm.  Is this something that we should sprint to fix or
  do we delay it to version 2.2 when there actually *are* a few
  archives people would want to discover?

* To express the location of the VTP endpoint, I have invented the
  x-vtp URI schema all that time ago.  Do people doubt that's a good
  idea (frankly: I do)?  And is the host name enough to "open" the
  stream or do we need a port, too?


Thanks,

           Markus

(who would really need a short introduction to VTP and all that's
related to it)


[1] To quickly look at it, use the old trick of prepending
https://dc.g-vo.org/I/ to it:
<https://dc.g-vo.org/I/ivo://org.gavo.dc/std/chime-frb/chime-frb>;
incidentally, that works for all valid ivo URIs.