Meeting at the Interop Nov 9, 2018
----------------------------------
Registry WG: Theresa Dower, Pierre Le Sidaner
ESA: Christophe Arviset, Juan Gonzalez, Kostandin Vrioni
SAO: Janet Evans, Menelaos Perdikeas, Yulie Zografou

The discussion was focused on the validation of registries by the RofR including the scope of the validation and the handling of failing registries now and in the future.

Registries failing validation
-----------------------------
1. Most of the registries are currently failing validation. Over the last few months we focused on analyzing the Euro-VO failures and drew the following conclusions:

- OAI validation errors were legitimate and registry changes were needed.
- Resource validation errors were also legitimate but difficult for the registry to have them fixed at this point.
- The Euro-VO Identity at some point was re-harvested and entered in the RofR manually by-passing the validation.
- Given the size of the effort to only partially solve validation errors with a single registry, we think that we cannot have all registries fixed, validated and updated in the RofR in the short term.


QUESTIONS/COMMENTS: 
- Should we re-harvest all registries, by-passing the validator?
- 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?
- The "score" suggestion, based on level of failure, came up (Janet). If pursued, score values would have to be defined and score will have to be carried along and displayed by applications. 
- There was also a suggestion (Juan) to always allow invalid registries in the RofR and periodically (prior to Interops) issue a validation failing reports.


ACTION:
- Review the attached additional-registry-validations.txt. If kept we will need a mechanism to clearly identify in standards documents such points for validation.


Scope of validation
-------------------
- The OAI validation should stay as is, at this point we are not aware of any problems with it. One "feature" is that it needs schema locations to be provided. We can change that, in the mean time it should be easy for the registries to provide them. People also want to see the lower level errors like a stack trace.

- There is an additional "IVOA profile" registry validation based on rules that are in additional-registry-validations.txt attachment.

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

- There are additional resource validations against the standards documents that need to be reviewed. The list is in additional-resource-validations.txt attachment.

- 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>


ACTION:
- Review the attached additional-resource-validations.txt. If kept we will need a mechanism to clearly identify in standards documents such points for validation.