access protocole key names in vor

[BaptisteCecconi]

Is there a reason to have an acc- prefix to all <key> elements in the VOEvent.vor document ? If there is a semantic meaning, it should be in an attribute, not in the name.

[BaptisteCecconi]

@msdemlei:
The new WD version is including a predefined list of protocole with acc- prefix, for VTP, XMPP and Kafka. An extra acc-proprietary one is defined for any other cases. As discussed offline with @Zarquan, this solution doesn't allow to easily add a new term when needed, and possibly adopted later.

I propose to allow an x-acc- prefix, for transport methods not yet available in the controlled vocabulary. This kind of practice is commonly used for experimental protocoles (and is actually in use in the current resrec-sample.vor example, with the x-vtp:// URL).

[msdemlei]

On Mon, Nov 09, 2020 at 01:19:40PM -0800, Baptiste Cecconi wrote: @msdemlei: The new WD version is including a predefined list of protocole with `acc-` prefix, for VTP, XMPP and Kafka. An extra `acc-proprietary` one is defined for any other cases. As discussed offline with @Zarquan, this solution doesn't allow to easily add a new term when needed, and possibly adopted later. I propose to allow an `x-acc-` prefix, for transport methods not yet available in the controlled vocabulary. This kind of practice is commonly used for experimental protocoles (and is actually in use in the current [resrec-sample.vor](https://github.com/ivoa-std/VOEvent/blob/master/resrec-sample.vor) example, with the `x-vtp://` URL).

Frankly, I think the idea of x-something has largely failed; the browser-specific draft css properties turned out to be a pest hard to get rid of again, and don't get me started on the fact that 20 years into the VO, we're still stuck with application/x-votable+xml as the VOTable media type, which is just again hurting us now that we'd need to define media type parameters. Given that, I confidently predict that, if the x- mechanism is used at all, we'll end up with x-whatever terms that will linger around for decades. What I'd do instead: People should just put in normal fragments. They'll be invalid for a while, but not in an obvious way, because who will actually check if these URIs resolve to something? So, that doesn't hurt, even less so because nobody (except their own experimental clients) can grok their streams anyway. Once the stuff becomes "standard" (in whatever sense of the word), we'll add that word to the registry record, and by the time things should be interoperable, their capability is valid, and we won't have any clients expecting x-whatever lingering around. I'll write this up into a PR if you want. But then: if you still think x- is a good idea, I'm not overly concerned either, and I'll not whine around if you write a PR suggesting that. While I think it'll not fly well, I also don't forsee major problems in actual operations (caveat: I don't really understand yet what VOEvent discovery will actually be used for, so there's a good chance I'm wrong with that gut feeling).

[Zarquan]

Part of this discussion came from my mis-interpretation of the standardID attribute.

The name of the standardID attribute, along with the acc-proprietary catch-all term in the vocabulary implies that the voe:StreamEndpoint@standardID attribute must be a reference to a term in the standard vocabulary.

I think that offering the acc-proprietary catch-all term will have the same issues as the x-something mime type. We will end up with lots of acc-proprietary entries and no one would register new protocols.

I also think that the text requiring a "consensus between the chairs of the IVOA DAL and Time Domain Working groups" to add new terms, while technically correct, will put people off.

However .. re-reading the proposed XML schema, I notice that the standardID attribute is listed as anyURI, which means that people can add in their own URIs for new protocols.

I suggest we change the description for the voe:StreamEndpoint@standardID to something more like the text describing the protocol identifiers in the VOSpace specification.

Start by saying it can be anyURI, then suggesting that they use a registry URI, and then follow that with a list of the existing standard protocols URIs already in the registry.

The current VOSpace schema defines Protocol identifiers as anyURI. The only restriction is that it SHALL be a valid (unique) URI.
A Protocol URI can be a simple URN, e.g., urn:my-protocol
This may be sufficient for testing and development on a private system, but it is not scalable for use on a public service.
For a production system, any new Protocols SHOULD have unique URIs that can be resolved into to a description of the Protocol.
Ideally, these should be IVO registry URIs that point to a description registered in the IVO registry:
ivo://my-registry/vospace/protocols#my-protocol
Using an IVO registry URI to identify Protocols has two main advantages:
IVO registry URIs are by their nature unique, which makes it easy to ensure that different teams do not accidentally use the same URI
If the IVO registry URI points to a description registered in the IVO registry, this provides a mechanism to discover how to use the Protocol

This has the same effect, in most cases the standardID attribute will be a URI that points to the list in the vocabulary, but it makes it clear that if people are using a new protocol they can start with anyRI and register it later. This lowers the barrier to registering new protocols and encourages people tell us more about their service.

[Zarquan]

TL;DR;

• Drop the acc-proprietary term from the vocabulary.
• Change to text to require anyURI and then recommend using the standard vocabulary where possible.
• Similar to the text for VOSpace protocol identifiers.

[msdemlei]

On Thu, Nov 12, 2020 at 03:21:22AM -0800, Zarquan wrote: I think that offering the `acc-proprietary` catch-all term will have the same issues as the `x-something` mime type. We will end up with lots of `acc-proprietary` entries and no one would register new protocols.

That one I doubt, because the point of the standardID is so that consumers can find streams they can parse, so there's a strong incentive to use something distinct that your consumers can work with.

I also think that the text requiring a _"consensus between the chairs of the IVOA DAL and Time Domain Working groups"_ to add new terms, while technically correct, will put people off.

Are you saying we should drop that language? The trouble is that StandardsRegExt (where the standard keys come from) doesn't say anything on how such term lists are to be managed. So, unless we say something on the management here, nobody can really touch the record. If all you're saying is: "That's too much if people just want to play around", I'm fine with that.

Start by saying it can be `anyURI`, then suggesting that they use a registry URI, and then follow that with a list of the existing [standard protocols](https://ivoa.net/documents/VOSpace/20180620/REC-VOSpace-2.1.html#tth_sEc3.5.3) URIs already in the registry.

I'm fine with allowing any URI here. However, I'd make it a SHOULD on using one of the keys in the VOEvent record (just to give people an incentive to get their protocol listed if they intend to keep running it), and a MUST if people run a protocol for which there already is a standard key. Saying "the following keys were registered when this specification was written:..." is a good thing, in particular because many people will have a hard time locating the registry record. I'll try to get the RofR to deliver an XSLT stylesheet with their records so we can happily link to something that'll look like http://dc.zah.uni-heidelberg.de/rr/q/pmh/pubreg.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo%3A%2F%2Fivoa.net%2Fstd%2Fregtap

> The current VOSpace schema defines Protocol identifiers as > anyURI. The only restriction is that it SHALL be a valid > (unique) URI. > A Protocol URI can be a simple URN, e.g., urn:my-protocol

Nah, let's not talk about URNs any more; that term has been deprecated for what, 10 years or so, and while we won't get rid of URL, that one doesn't need to propped up. If you really want to say something in addition to "use a URL", make it "When using a non-ivo URI, it is recommended to make it resolve to a specification of the transport protocol." So... will you write the PR or should I?