<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p><br>
</p>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Markus Demleitner <msdemlei@ari.uni-heidelberg.de><br>
<b>Sent:</b> Monday, November 19, 2018 5:20 AM<br>
<b>To:</b> Zografou, Panagoula<br>
<b>Cc:</b> Janet Evans; Theresa Dower; Pierre Le Sidaner; Christophe Arviset; Kostandin Vrioni; Juan Gonzalez; Menelaos Perdikeas; Harbo, Peter<br>
<b>Subject:</b> Re: RofR meeting notes</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
> On Wed, Nov 14, 2018 at 01:09:46PM -0500, Zografou, Panagoula wrote:<br>
<font size="2"><span style="font-size:10pt;">> </span></font>> - Should we re-harvest all registries, by-passing the validator?<br>
<br>
<font size="2"><span style="font-size:10pt;">> </span></font>There's not much point running the whole enrollment procedure for<br>
<font size="2"><span style="font-size:10pt;">> </span></font>every update. What needs to be done, though, is regularly<br>
<font size="2"><span style="font-size:10pt;">> </span></font>re-harvesting the registry record itself. I *suppose* just going for<font size="2"><span style="font-size:10pt;"><br>
</span></font></div>
<div class="PlainText"><font size="2"><span style="font-size:10pt;">></span><span style="font-size:10pt;"></span></font>what comes back from verb=Identify would be enough, but I'd really<br>
<font size="2"><span style="font-size:10pt;">> </span></font>prefer trying verb=GetRecord&identifier=<registry-id>, as that<br>
<font size="2"><span style="font-size:10pt;">> </span></font>would catch more subtle failures.<br>
</div>
<div class="PlainText"><br>
<font size="2"><span style="font-size:10pt;">> </span></font>If what's coming back there fails some basic validation, that's a<br>
<font size="2"><span style="font-size:10pt;">> </span></font>reason for concern and should probably block updates to the RofR.
<br>
</div>
<div class="PlainText"><font size="2"><span style="font-size:10pt;"><br>
>The most important thing to check, I think, would be if a registry<br>
>claims someone else's managedAuthorities.</span></font><br>
</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">Off the top of my head, the only thing in the RofR that could update and affect an individual registry owner's validation status outside of their own local updates are
<br>
</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">1: new standards updates, which could validate previously in-valid records, which doesn't happen often</div>
<div class="PlainText">2: other registries' managedAuthority changes, which, well, might?</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">Therefore I think while ongoing validation monitoring by third parties (whether it be the RofR or the Euro-VO weather report, or something else) is a good thing, a good low and useful bar would be to periodically check the Identify record
for validation and managedAuthority issues, with manual followup as Markus mentioned.
<br>
</div>
<div class="PlainText"><br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>> - Should we set a time by when all currently registered registries<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>> must succeed validation and after that any new or updated<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>> registries will be required to comply?<br>
<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>While it would be useful to impress the importance of correct<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>registry records on the operators, I suppose there's no real need to<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>be heavy-handed. The searchable registries deal ok with the sorts of<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>minor failures that are fairly common.<br>
<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>I like Juan's proposal of sending, perhaps twice a year, a text<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>version of the validation report to the contact addresses of the<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>registries.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">I believe at the meeting consensus was leaning towards something like the latter, out of concerns being too heavy-handed on validation would knock very useful and compliant services in registries with unrelated issues out of search listings,
and since we still have issues with the validation itself this isn't the time anyway. So, perhaps more importantly we came to a consensus about RofR and other maintainers of resources and software doing our best-effort by the next interop, seeing where we
are then and what intractable problems remain (including technical issues but also support level for various registries' operations), and letting that inform the process moving forward.
<br>
<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>> - For resource XSD validation, it was agreed to keep it and also<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>> provide lower level errors like a stack trace.
<br>
<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>Is that really useful? We should, anyway, make sure the reports<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>don't become even more hard to read than they already are.<br>
<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>What I think would be helpful would be a reviving and reviewing the<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>explanations for the various errors (the ones you get when you follow<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>the links under the error codes; right now, examples look like<br>
<a href="http://rofr.ivoa.net/regvalidate/not_available.htm#OAIvalid" id="LPlnk294403" previewremoved="true"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>http://rofr.ivoa.net/regvalidate/not_available.htm#OAIvalid</a>).
I'd<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>volunteer for having a go at what *I* understand if you tell me where<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font></span></font>what's still there is.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">With my registry devops hat on, there are cases where I'd like to see the stack trace or just more error information in general at the bottom of the links under the error codes. Some of them were really not obvious, though a few minutes
of explanation by Menelaos cleared it up. I agree we shouldn't just dump the whole thing on the user in what could be an already crowded page.<br>
<br>
<font size="2"><span style="font-size:10pt;">></span></font>> - There is a discrepancy in some IVOA documents that causes some of<br>
<font size="2"><span style="font-size:10pt;">></span></font>> the XSD validation failures. Standards documents give examples of<br>
<font size="2"><span style="font-size:10pt;">></span></font>> ivo-id's that include a '#' but VOResource-v1.0.xsd or<br>
<br>
<font size="2"><span style="font-size:10pt;">></span></font> These should be fixed in later versions or errata. If you find<br>
<font size="2"><span style="font-size:10pt;">></span></font>anything that's still wrong, let me know.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">This particular errata is on my todo list, though someone can pick it up if they want to!
<br>
</div>
<div class="PlainText"><br>
</div>
<div class="PlainText"><br>
</div>
<div class="PlainText"><br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>> - A Harvesting Registry must return VOResource records when metadataPrefix=ivo_vor<br>
<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>This should be "Publishing Registry", right?</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">(I'm assuming yes here, but possibly arguing below that searchable registries also must have an endpoint for this)<br>
<br>
<font size="2"><span style="font-size:10pt;">></span></font>I actually have an issue with this requirement (and it's still being<br>
<font size="2"><span style="font-size:10pt;">></span></font>imposed) on searchable registries. For these, it may be perfectly<br>
<font size="2"><span style="font-size:10pt;">></span></font>sensible to have an oai-pmh endpoint without any records of its own;<br>
<font size="2"><span style="font-size:10pt;">></span></font>the ones associated with my RegTAP services are examples. I'd like<br>
<font size="2"><span style="font-size:10pt;">></span></font>i<font size="2"><span style="font-size:10pt;"></span></font>t a lot if only publishing registries were requried to actually have<br>
<font size="2"><span style="font-size:10pt;">></span></font>at least one record.
<br>
<br>
<font size="2"><span style="font-size:10pt;">></span></font>Incidentally, I don't register these OAI-PMH endpoints for exactly<br>
<font size="2"><span style="font-size:10pt;">></span></font>that reason.<br>
<br>
<font size="2"><span style="font-size:10pt;">></span></font>> - Registry resource should have one capability with either xsi:type='vg:Search' or xsi:type='vg:Harvest'<br>
<br>
<font size="2"><span style="font-size:10pt;">></span></font>That one should be dropped. RegTAP registries, for instance, can<br>
<font size="2"><span style="font-size:10pt;">></span></font>perfectly work with just a TAP or auxiliary TAP capabilitiy.<br>
</div>
<div class="PlainText"><br>
</div>
<div class="PlainText"><br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>> - ListRecords must include the record for the registry being tested.<br>
<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>That one should also only be enforced for publishing registries, not<br>
<font size="2"><span style="font-size:10pt;"><font size="2"><span style="font-size:10pt;">></span></font></span></font>of OAI endpoints of searchable ones.</div>
<div class="PlainText"><br>
</div>
<div class="PlainText"><br>
I'm either misunderstanding or disagreeing with a key point in this bit about RegTAP. IVOA registries are, on a fundamental level, built on the OAI-PMH design, and the concept of a searchable registry is built on top of a publishing one, whether it has any
records beyond Identity (and associated authority and/or organisation, etc) of its own or not. Even a searchable registry with only RegTAP and basic OAI endpoints should have self-reflective resources (i.e. identify) for contact information, and an authority
record would go with it. And we need to serve up SOME VOResource record in ivo_vor format (i.e. at least a vg:Harvest capability) in that case; a RegTAP query can't fully construct that XML resource. Are you arguing that those bookkeeping records don't count,
or don't have to exist? Or does this come from having the RegTAP service resource be separate from what you would register the OAI one as if it could be registered without records to list? Also this seems to go counter to the comment above suggesting we pull
from GetRecord instead of Identify. I know I'm missing something here, can you explain a bit more?</div>
<div class="PlainText"><br>
</div>
<div class="PlainText"><br>
</div>
<div class="PlainText">Thanks for writing this up and sorry it took me a bit to get to, hopefully we can spin this discussion, and the work to resolve the issues, started back up.</div>
<div class="PlainText">--Theresa<br>
</div>
<div class="PlainText"><br>
</div>
<div class="PlainText"><br>
</div>
</span></font></div>
</div>
</body>
</html>