[ivoa-std/VOEvent] Registry matters (#11)

[Dave Morris]

I think we are just disagreeing about the sequence we do the steps.

Your proposal is to accept this PR now, as-is, with the MUST 
requirement, and then look at changing the rest of the standard to 
resolve the larger question about service discovery and query later.

I'm wary of adding more text reinforcing the MUST requirement because 
past experience says it will be hard to remove later. I'd prefer to make 
the text more permissive, using IF and SHOULD rather than MUST, and 
allow people to choose.

I'd like to find a way of avoiding adding another MUST, and make a start 
on moving the main text towards a more flexible and inclusive form that 
enables people to have public (registered) and private (internal) 
services.

If we make it easy and useful to register, then most people will 
register them, without us having to resort to MUST in the specification.

If we add more MUSTs to the specification and people still don't 
register their services, then we end up with more non-standard services.

As far as I know this is the only IVOA specification that actually 
requires the service to be registered. It is perfectly legitimate to 
create a local TAP service that is 100% standards compliant that can be 
used by PyVO, Aladin and TopCat based on just the endpoint URL.

The DALI/TAP specification allows (MAY) a TAP service to include an INFO 
element in the VOTable results RESOURCE element with details of the 
original query, but DALI/TAP doesn't require (MUST) the results to 
include a resolvable IVORN of the service.

Perhaps the DALI/TAP specification should include a include a resolvable 
IVORN of the service in the results, but if it did, it would likely be a 
MAY not a MUST.

-- Dave


On 2020-11-03 08:40, msdemlei wrote:
> On Mon, Nov 02, 2020 at 08:11:24AM -0800, Zarquan wrote:
>> > There's also the "Public VOEvent Streams MUST be registered" matter. Again, I'd suggest to merge into the document as-is, because there's really little choice in this matter as long as event ids are ivoids.
>> 
>> We do have a choice. As described on the mailing list, we can change 
>> the wording in this PR to remove the MUST and change it to say "IF you 
>> are registering a stream, this is how".
> 
> The trouble with this is that then the identifiers of the VOEvents
> are invalid (or at least in contradiction to IVOA Identifiers);
> there, it's clear that if you have a URI in the ivo scheme, the URI
> (as usual, excluding query and fragment) must resolve in a registry.
> 
> One could conceivably to say "Register something else and build your
> event ids from this"; that's still a mild violation of the URI
> spirit, though (the VOEvents pretend to be "generatable" from the
> registered URI.
> 
> So -- let's do the right thing and drop the ivoid requirement for
> VOEvents.  But that's beyond this PR and needs to be discussed after
> we merge this, together with an explicit statement that
> non-registered VOEvent streams are use case.  The problem will also
> become a bit easier to state then, because we can say "the id of a
> VOEvent from a registered VOEvent stream SHOULD consist of the
> stream's ivoid and an arbitrary fragment identifiers.  While other
> identifier schemes are allowed, VOEvent identifiers MUST NOT be built
> using ivoids other that the VOEvent stream's.
> 
> Once something like that is done, we can tone down (or rather, make
> more concrete, as we don't really explain what the "public" is in the
> contentious sentence) the language in the registry chapter, too.