RofR extended validation changes

[Markus Demleitner]

Hi Registry,

On Tue, Mar 12, 2019 at 07:43:29PM +0000, Theresa Dower wrote:
> Catching up on discussion about validation in the RofR, I went over
> the additional validation checks that it runs against registries
> apart from the main OAI-PMH 2.0 and VO resource .xsd standards
> validation steps.
> 
> I only see a couple of changes we should make *given the current
> snapshot of standards*, one of which has been temporarily done
> already. I'm posting this to the whole list not just for
> transparency but in hopes folks will double-check this before we
> revisit it at the May 2019 interop and weigh in.

[...]
> - Search capability must include interface with xsi:type='vr:Webservice' and role='std'

I think this is so outdated that we might as well drop it now.
An additional reason would be that role='std' should refer to a
standard which, now that RI 1.1 has superseded RI 1.0, no longer
really exists.

If we still keep it, we should at least add a comment like:

  This refers to RI 1.0 endpoints, which were SOAP-based.  2019: Since
  there might still be sporadic use of this, we've not dropped it.
  It should be safe to drop when you read this and don't understand
  what it means any more.

> - The Registry must not serve records authorities it does not claim
> in its Identify response ("managedAuthority")

Assuming this is inteded to meand "serve records *from* authorities"
and this description is somehow semi-official, we should add "when
called with set=ivo_managed" here.  I'm sure that's what the
validator does already, as quite a few registries would otherwise be
invalid.

>         - ListRecords must include the record for the registry being tested.

I'd still like to drop this, as I don't see operational problems when
there's an OAI-PMH endpoint that not self-registers, and then doesn't
return anything for sets=ivo_managed at all.  My examples are the
OAI-PMH endpoints associated with my RegTAP services; you can use
them to retrieve full records for any ivoid in the registry (there
are quite a few use cases for having such a beast.

It's really much more convenient if some other publishing registry
carries the RegTAP services resource record, which includes an
OAI-PMH capability that one might want to validate.  So, if we can
reasonably get rid of that constraint, I'd like it a lot.

Alternatively, perhaps there really is a point for having two
"levels", one for just "OAI-PMH in the VO", the other for "publishing
registry" (for which a complete lack of records certainly indicates a
problem; I'm still not sure we should force them to self-register).

           -- Markus