Registry Interfaces 1.1 - drafts post-Stellenbosch

[Markus Demleitner]

Dear Theresa,

On Mon, May 23, 2016 at 04:39:49PM +0000, Theresa Dower wrote:
> 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 prevent possible confusion as to who's supposed to use the RofR's
OAI endpoint, perhaps we should say:

  "...enroll it in the RofR so searchable registries (and
  consequently clients) will be able to find their records..."

> 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

Since the RofR doesn't do authority checking right now, and there is
probably no need to actually have this in the norm, I think it's ok
to leave this out of the standard at this point (as suggested by you
futher down in the thread).

> 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?).

What changes do you have in mind?  As far as I can see, we'd only
need to change some text annotation.   Essentially, the second
annotation on vg:Registry right now says:

  A registry is considered a publishing registry if it contains a
  capability element with xsi:type="vg:Harvest". It is considered a
  searchable registry if it contains a capability element with
  xsi:type="vg:Search".

-- and at least the second sentence in there would be wrong (a RegTAP
searchable registry would have either a TAP capability or a TAP
auxiliary capability and, I'd say, the RegTAP tableset, perhaps as
http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/rr/q/create,
just with vg:Registry as xsi:type).  I'd say if that's all we change,
we'd do the world a favour if we did the change without introducing a
new version (which always incurs a certain amount of pain).

Do you see other places we need to touch?

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

Strictly, yes.  I also don't think there's a technical reason to shun
a major version jump, although 1.1 to me looks a bit more mature than
2.0 (in this day and age of bananaware), but that's probably just me.

Still, if it's just the requirement of VOSI that would make us bump
the major version, I think I'd just downgrade the VOSI language to a
strongly recommend and keep it to a minor version bump, just to avoid
terribly high expectations that something revolutionary has happened
in RI.  On the other hand, we're now documenting the RofR, which in
itself might count as a major change.  Ah well.  Count me as
undecided.

    -- Markus