Registry Interfaces 1.1 - drafts post-Stellenbosch

[Theresa Dower]

Yulie,

Oh dear. I’ll definitely clarify, though it looks like we may have to take that out or add some changes to the validator. At this point I feel terrible about asking for any more changes, so perhaps we should just leave it out.

What I mean by authority uniqueness is that when a new registry record contains a list of managedAuthorities (which it should), none of those listed managedAuthorities are already claimed by other registries in the RofR. This does happen sometimes when records are being transferred, and while orphan records (i.e. “ivo://nowhere.nothing/ConeSearch” where “ivo://nowhere.nothing” is not claimed by any vg:Registry resource in the RofR) happen sometimes, that’s a far less bad thing than having multiple registries claim the same managedAuthority. Similarly all of the records in the new registry should have identifiers that start with a managedAuthority it claims to own. I thought we were checking against part of this. If we’re not, I can take out the wording for now?

Thanks for bringing this up!
--Theresa

From: Zografou, Panagoula [mailto:pzografou at cfa.harvard.edu]
Sent: Monday, May 23, 2016 3:14 PM
To: Theresa Dower
Cc: registry at ivoa.net
Subject: Re: Registry Interfaces 1.1 - drafts post-Stellenbosch

Hi Theresa,
Can you please explain what you mean by "including authority uniqueness" on the list of things that the validator checks. We do not see anything in the code that relates to it.
Thanks,
Yulie

On Mon, May 23, 2016 at 12:39 PM, Theresa Dower <dower at stsci.edu<mailto:dower at stsci.edu>> wrote:
Registry folks,

Personally, I'd prefer generalizing the RofR link-related text to make it less dependent on the particular current architecture, so I'm in favor of this change! There's a little more detail in the paragraph I'd like to keep, so I'm integrating this wording with the existing text a little.

What I have right now is:

Once a registry provider has deployed a new publishing registry, they must enroll it the RofR for clients and full-search registries to be able to find their records. The RofR provides a dedicated web-based interface for this purpose accessible from http://www.ivoa.net.  The RofR includes a validator package, which thoroughly checks the new registry, including schema validation for the OAI interface itself and all listed resources, plus provenance issues including authority uniqueness. The registration process will only accept registries that validate successfully.  Local updates within a publishing registry post-inclusion in the RofR are not necessarily automatically validated by the RofR software later: the validator tool can, and indeed should, be used independently of the first admission process by the registry providers to periodically make sure their registries are still compliant with the relevant IVOA standards.

---

For further changes, I'm working (with Markus) on including a new method for identifying full searchable registries, which isn't finished yet: interfaces like SOAP/XQuery will still be allowed but that one will not be considered the defining feature. This will require changes in the text and additions to the VORegistry-1.0 schema (now 1.1?).

Also, I note that while dropping requirements is one thing, we're newly requiring VOSI endpoints. Does this make Registry Interfaces not backward-compatible? Does this therefore become a 2.0 document/change? I think so.

Next draft will be circulated to list once I sort out a preliminary fully searchable registry description. In the meantime, comments encouraged on the RofR paragraph above or any of the remaining issues.

--Theresa


> -----Original Message-----
> From: registry-bounces at ivoa.net<mailto:registry-bounces at ivoa.net> [mailto:registry-bounces at ivoa.net<mailto:registry-bounces at ivoa.net>] On Behalf
> Of Markus Demleitner
> Sent: Monday, May 23, 2016 5:04 AM
> To: registry at ivoa.net<mailto:registry at ivoa.net>
> Subject: Re: Registry Interfaces 1.1 - newest draft pre- Stellenbosch session
>
> Dear Registry,
>
> On Thu, May 19, 2016 at 02:42:48PM -0400, Zografou, Panagoula wrote:
> > Is it necessary to fix the RofR validator URL
> > http://rofr.ivoa.net/regvalidate in section 4.1? We understand that it
> > was carried over from the RofR note but does it belong in the
> > recommendation as a 'standard service'? The validate/register page is
> > accessible as a link from the main RofR page http://rofr.ivoa.net and
> > one does not need to know its absolute path. Making it abstract would
> > give us more flexibility in maintaining the application.
>
> I agree -- let's not codify more than we need to.
>
>
> I'd say let's replace the entire paragraph starting with "Once a registry provider
> has deployed a new publishing registry..." with something like:
>
>   Once a registry provider has deployed a new publishing registry,
>   they have to register it with the RofR, which provides a dedicated
>   browser-based interfaces for this purpose accessible from
>   http://www.ivoa.net.  The RofR performs a thorough validation of
>   the new registry, and it will refuse to add invalid registries.
>   This validator can, and indeed should, be used independently of the
>   first registration process by the registry providers to
>   periodically make sure their registries are still compliant with
>   the relevant IVOA standards.
>
> I wonder if even the "browser-based" is too strong.  It doesn't rule out other
> interfaces, though, so perhaps it's not too strong a statement.
>
> Cheers,
>
>           Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160523/d378c1cf/attachment-0001.html>