Registry Interfaces 1.1 - drafts post-Stellenbosch

[Theresa Dower]

Markus et al,

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

I like it. Fixed. Also removed the reference to provenance-related validation of authority records unless/until anyone else speaks up with a compelling argument for it along with  a willingness to write the validator code themselves and the RofR maintainer's agreement.

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

It's mostly text annotation, but when we get to search, there's xquery-specific definitions including an enumerated type which should either be expanded or removed (especially since the xquery search is no longer described in the most current version of the RI document), plus the whole concept of the TAP capability as you've illustrated below.

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

 Ok. I'm just typing out draft thoughts here, bear with me.

* We need to allow for RegTAP capabilities to count as searchable - but not exclude existing XQuery.
* We need to allow for RegTAP capabilities to NOT count as "full" -- ROE wants to add RegTAP to their general TAP services since they've also got a registry anyway and this is reasonable enough to allow.
* Therefore we need a way to mark "full" searchable without relying on xQuery OR the existence of a RegTAP service.

SO:
* (This goes in a new optional vg:Registry element)  OR
* (change to searchable to allow RegTAP capability/tableset AND some optional 'full'ness element is added) OR
* (Something with #aux that I don't understand) ?
	
..and  I'd prefer that middle option, but think it counts as a change to the schema.


> Do you see other places we need to touch?

Not yet; I'm still poring over it but I think this is it.

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

I think between adding the RofR, potential schema addition, and VOSI it counts as a 2.0 document. I don't have much experience with the IVOA docs process beyond responding to RFCs though, and can easily be argued down from this point.
 
>     -- Markus

--Theresa