Registry Interfaces 1.1 - drafts post-Stellenbosch

[Zografou, Panagoula]

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> 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] On
> Behalf
> > Of Markus Demleitner
> > Sent: Monday, May 23, 2016 5:04 AM
> > To: 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/1bd24d47/attachment.html>