Fw: RofR meeting notes

[Theresa Dower]

As promised, bringing the resultant discussion from the RofR meeting to the rest of the list.

________________________________
From: Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Sent: Monday, November 19, 2018 5:20 AM
To: Zografou, Panagoula
Cc: Janet Evans; Theresa Dower; Pierre Le Sidaner; Christophe Arviset; Kostandin Vrioni; Juan Gonzalez; Menelaos Perdikeas; Harbo, Peter
Subject: Re: RofR meeting notes

Hi all,

I suppose we could take some of these points to the registry mailing
list for transparency (though I suppose the addresses of this mail
cover about all the interested folks).  Anyway, a few remarks from
me:

On Wed, Nov 14, 2018 at 01:09:46PM -0500, Zografou, Panagoula wrote:
> - Should we re-harvest all registries, by-passing the validator?

There's not much point running the whole enrollment procedure for
every update.  What needs to be done, though, is regularly
re-harvesting the registry record itself.  I *suppose* just going for
what comes back from verb=Identify would be enough, but I'd really
prefer trying verb=GetRecord&identifier=<registry-id>, as that
would catch more subtle failures.

If what's coming back there fails some basic validation, that's a
reason for concern and should probably block updates to the RofR.

So, I'm monitoring the publishing registries in the sense that
each Wednesday, my harversters send me a mail what's currently
broken, and after a couple of weeks of breakage I usually follow up
manually.  If the RofR could do a similar thing, that'd lighten my
load.

The most important thing to check, I think, would be if a registry
claims someone else's managedAuthorities.

> - Should we set a time by when all currently registered registries
> must succeed validation and after that any new or updated
> registries will be required to comply?

While it would be useful to impress the importance of correct
registry records on the operators, I suppose there's no real need to
be heavy-handed.  The searchable registries deal ok with the sorts of
minor failures that are fairly common.

I like Juan's proposal of sending, perhaps twice a year, a text
version of the validation report to the contact addresses of the
registries.

> - For resource XSD validation, it was agreed to keep it and also
> provide lower level errors like a stack trace.

Is that really useful?  We should, anyway, make sure the reports
don't become even more hard to read than they already are.

What I think would be helpful would be a reviving and reviewing the
explanations for the various errors (the ones you get when you follow
the links under the error codes; right now, examples look like
http://rofr.ivoa.net/regvalidate/not_available.htm#OAIvalid).  I'd
volunteer for having a go at what *I* understand if you tell me where
what's still there is.

> - There is a discrepancy in some IVOA documents that causes some of
> the XSD validation failures. Standards documents give examples of
> ivo-id's that include a '#' but VOResource-v1.0.xsd or
> VOResource-v1.1.xsd do not allow it, for example:
>
> http://ivoa.net/documents/SimpleDALRegExt/20170530/REC-SimpleDALRegExt-1.1.html
> ivo://ivoa.net/std/SIA#query???2.0
>
> http://www.ivoa.net/documents/RegTAP/20180731/PR-RegTAP-1.1-20180731.html
> <dataModel ivo-id="ivo://ivoa.net/std/RegTAP#1.1"
>   >Registry 1.1</dataModel>

These should be fixed in later versions or errata.  If you find
anything that's still wrong, let me know.

>         - A Harvesting Registry must return VOResource records when metadataPrefix=ivo_vor

This should be "Publishing Registry", right?

I actually have an issue with this requirement (and it's still being
imposed) on searchable registries.  For these, it may be perfectly
sensible to have an oai-pmh endpoint without any records of its own;
the ones associated with my RegTAP services are examples.  I'd like
it a lot if only publishing registries were requried to actually have
at least one record.

Incidentally, I don't register these OAI-PMH endpoints for exactly
that reason.

>         - Registry resource should have one capability with either xsi:type='vg:Search' or xsi:type='vg:Harvest'

That one should be dropped.  RegTAP registries, for instance, can
perfectly work with just a TAP or auxiliary TAP capabilitiy.

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

That one should also only be enforced for publishing registries, not
of OAI endpoints of searchable ones.

> - Recommend setting VOResource xsi:type='vs:CatalogService' on service with SimpleImageAccess capability

This (and a few similar rules) might need to be dropped in the
future, but for now it's fine.

Thanks for looking into all this,

          Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20181204/93f9b4ce/attachment-0001.html>