Registry Interfaces 1.1: WG comments?

[Markus Demleitner]

Hi Theresa, dear Registry community,

On Sat, Aug 29, 2015 at 03:27:52PM +0000, Theresa Dower wrote:
> Hello! Myself and Markus have been working on the updated Registry
> Interfaces document for a bit now, and I'd like to submit changes
> for comment within the working group before any formal RFC.
> 
> I will note that I'm currently having issues with LaTeX packages on
> Windows; consequently references are not showing up properly right
> now in the PDF. There aren't many and they should be obvious but
> I'd very, very much appreciate if someone could test out Markus'
> new volute repository at   https://volute.g-vo.org, where I've
> checked it in, and try building it on a more civilized operating
> system.

I've built the document, and all is well -- the document with
references is at http://docs.g-vo.org/RegistryInterface.pdf

Plus, here's some brief comments on the changes --

> using the Registry of Registries.
> 
> 
> I would particularly like some wordsmithing input on this,
> meta-registry writing gets tangled. I'm not entirely comfortable
> putting the direct links to RofR web presence in the document, but
> it doesn't exactly change, and we'd have to reference it somewhere,

Well, I think we necessarily have to put in fixed URLs -- readers of
the document should have something to put into their browsers or
clients to jump into the registry.

Howwever, the actual URL, 

  http://rofr.ivoa.net/cgi-bin/oai.pl

IMHO is not ideal, as it communicates two technology choices -- CCI
and Perl -- that may change and even today smell a bit stuffy to
several noses.  I'd much rather have a generic URI that would be
mapped by ScriptAliases or whatever URI mapping mechanisms future
servers have.  I'd propose

  http://rofr.ivoa.net/oai

-- what do the current maintainers of the RofR think?  Would you see
an issue with adding

ScriptAlias /oai <path-to-wherever>/cgi-bin/oai.pl

into your apache config[1]?

Similarly, I'd much prefer http://rofr.ivoa.net/add-registry (or
similar) to http://rofr.ivoa.net/regvalidate/regvalidate.html --
which again contains a bit too much implementation detail.


Further comments:

(2) The current text has

  The Registry of Registries includes the VOResource records directly
  representing each currently active registry of IVOA resources, be they
  fully searchable or providing only an OAI-PMH harvesting interface.

-- this is a problem I've been thinking about for a while now without
having stumbled on a deep and satisfying insight.  While I believe it
makes a whole lot of sense to have the searchable registries in RofR,
too, with current RegTAP these don't have a specific registry record
any more, let alone a vg:Registry-typed one.

Right now, RegTAP registries are just TAP services with a proper data
model declaration.  Pulling these into the RofR is probably not a
good idea (there can be, and already is in some cases, lots of other
junk in the services), plus of course these records are not
vg:Registry-typed.

I could well imagine just putting in a TAP capability into a
vg:Registry element, plus perhaps the relational registry table
schema.  In that case, we'd have to change the annotation on
vg:Registry in the schema, which currently 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".

With the proposed change, this would have to be something like

  A registry is considered a publishing registry if it contains a
  capability element with xsi:type="vg:Harvest". Other capabilities
  may be given, including the legacy vg:Search (for the old, RI 1.0
  search interface) or a TAP capability (Dowler et al...) with a
  dataModel http://ivoa.net/...RegTAP... for a RegTAP-searchable
  registry.

I'd feel a lot more relaxed with that if we implemented proper XSLT
for that on the RofR first.  Another thing I really don't like about
this is that so far, endpoint discovery usually works via a standard
id, not via a resource type.  This stuff would be the first
excpetion.

Hence: Good ideas solicited.

Anyway, whatever we do for extra, stand-alone RegTAP records would
have to be specified in RI for the time being -- we don't want to
wait for RegTAP-Next with that.  When we reach a consensus on what to
do here, I'll happily contribute.


(3) The current text has 

  Upon successful validation, the publishing registry will be
  automatically included in the RofR listing...

-- which I believe is not what happens nor what should happen.
Developers are welcome to validate their Registry often and early
without having to fear premature publication (I, for one, was happy I
could do that and still can with my development site).  I've already
changed that to

  Upon successful validation, the publishing registry may be 
  included in the RofR listing at the user's option,...

In Rev. 3051. Agreed?


(4) The current text has:

  ...updates to the Registry record itself are not automatically
  reflected in the RofR contents.

...which has bugged me for a while now.  I am fairly convinced the
whole system would work better if the RofR went out to re-havest the
records of the publishing registries and warned somebody (I'd
volunteer for the duration of my term) when things break (e.g., two
registries claiming the same authority).

I don't think this spec is a good place for laying down such
operational aspects (or is it?  After all, this is all about the
operation of the VO Registry... hm), but at least we  shouldn't
indicate that you can expect to get away with anything once you are
in the RofR.  Hence, I'd vote for striking this.


(5) In a similar vein, I believe we'd help the RofR operators if we
indicated somewhere under which conditions records will be removed
from the RofR.  I'd roughly say: When a Registry produces invalid
content or announces dead services as active for X months and the
operators haven't responded to at least three communication attempts,
their registry will be removed from the RofR as dead.  Or something
like that.  I realise that's a highly political issue, so we should,
in TCG review, say, explicitely point to this question.


Sorry this got a mouthful, but the whole RofR business is new in REC
(it's been a note so far), and we should use the opportunity to think
things through again, drawing on the experiences we've made.

Thanks,

          Markus



[1] Incidentally, at the GAVO data center, we're using oai.xml rather
than oai, as that gives a useful extension to the document when
saving from popular clients like curl.  I'm not sure if I'd like to
propose this fake extension as a central IVOA policy.