Adding a StandardsRegExt record for VOEvent. #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This ought to be mailed to the RofR as soon as we're happy with it, and then updated when a new version is issued. I've taken the liberty to include a few standard keys required in the proposal for registering VOEvent streams that'll come in a separate PR. They don't hurt if if that's rejected (but probably should still be taken out if that happens).
This commit also adds a "proprietary" access protocol as a catch-all option.
Zarquan
reviewed
May 18, 2020
|
|
||
| <endorsedVersion status="rec">2.0</endorsedVersion> | ||
|
|
||
| <key> |
There was a problem hiding this comment.
I'm not convinced this should be a fixed list. Is there a way to refer to the transport standards using a list of URIs ?
Zarquan
reviewed
May 18, 2020
Zarquan
reviewed
May 18, 2020
| <curation> | ||
| <publisher>IVOA</publisher> | ||
|
|
||
| <creator><name>Seaman, Rob</name></creator> |
There was a problem hiding this comment.
List of creators to be updated after the current PR v2.1
|
On Mon, May 18, 2020 at 02:41:44AM -0700, Zarquan wrote:
+ <key>
I'm not convinced this should be a fixed list. Is there a way to
refer to the transport standards using a list of URIs ?
capability/@standardID is just a URI. What the standard keys do is
establish a set of URIs that are easy to recognise (and which have
well-defined comparison rules).
Of course individual projects can use any URIs they like, but that's
probably not making clients' lives easier.
Also, we could say that VTP ought to use that standard's putative
ivoid (but for all I know nobody bothered to put in a StandardsRegExt
record for it, so formally that ivoid doesn't exist). I put it in as
an extra standard key here because it makes it a bit easier to
recognise "standard", agreed-upon transport protocols. But there'd
be no material difference, and using the standards' ivoids might even
be preferable if we expect more transport standards becoming IVOA
RECs.
As to the fixed list: This stuff is put into the standards record so
it can be changed without having to change the standard. We don't
have global policies for how such key lists are maintained, and the
standard can (and IIRC will in a PR I'll put in when my example
service is ok with the sample record) say when and how such keys can
be added.
|
|
On Mon, May 18, 2020 at 02:44:52AM -0700, Zarquan wrote:
+ <key>
+ <name>acc-xmpp</name>
+ <description>
+ In an interface's standardID, this identifies an interface that gives
+ access to the VOEvent stream using an informal method based on
Why is this one informal ?
Mainly because I don't know where it's specified. For VTP, there's a
REC, so that's easy. If there's some document on that, we can put
its URL in there and strike the "informal".
I guess that would apply to rabbitmq, too. Does anyone use that? If
so, could they perhaps make a quick IVOA note on it?
|
I agree a note on how it is used would be good. |
I have no opinion but please @ your collaborator |
|
Sorry to the other |
Apologies for @'ing a random bystander. |
BaptisteCecconi
added a commit
that referenced
this pull request
May 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This ought to be mailed to the RofR as soon as we're happy with it, and
then updated when a new version is issued.
I've taken the liberty to include a few standard keys required in
the proposal for registering VOEvent streams that'll come in a separate
PR. They don't hurt if if that's rejected (but probably should still
be taken out if that happens).