Registry interfaces internal working draft

[Markus Demleitner]

Dear Registry WG,

In Banff I promised I'd provide a fixed-up version of the Registry
Interface document ("RI2") RSN.  The main change in the document
is the removal of the search interface; this was decided in Sao Paulo
to allow the separate evolution of client interfaces.  Now that the first
of these external search interfaces, RegTAP, is REC, it's time we
no longer require the RI1 search capability (in particular, since
supporting old-style ADQL via SOAP is really becoming painful).

While doing this, it turned out that surprisingly many parts of the
text referred to what was section two (the search interface), and
so the actual amount of editing is fairly extensive.

The normative content outside of search hasn't changed (much),
though, so if you're running a publishing registry now, you shouldn't
need to do anything (well, the standards police might come after you
if you don't provide your VOSI endpoints, but it could have done that
already).


So here's the changelog as of now:

\item Removed the entire section 2, specifically the SOAP-based services
based on ``ADQL 1.0'' and XQuery.

\item Dropped the requirement on registries to not deliver any records that are OAI-PMH deleted when no temporal constraint is given.

\item Announcing a migration to
\nolinkurl{ivo://ivoa.net/std/Registry#OAI-2.0} as the harvesting
capability's standard id on a
schema change.

\item Added a requirement to provide VOSI endpoints.

\item Clarified that the requirement to keep deleted records for six
months only applies to the transient case; also discouraging registries
with no support of deleted records.

\item Many editorial changes across the text, mostly as a consequence of
externalizing the search interface.



There are some additional things I might want to change but which I'd
appreciate input on first.  If you have input to mulitple of these
points, please reply in different mails so the discussions remain
manageable.

(a) Shouldn't the RofR be at least mentioned here?  While I agree
that in everyday Registry operations, its impact is fairly moderate,
mentioning here that the IVOA operates a special registry will, I
think, make things much clearer.  And no, the RofR note wouldn't be
obsoleted by this, as, for instance, the validation aspects IMHO
don't really need any normative language.

(b) I always felt it was a bit of a pain that you had to discover
support for seconds-granularity in OAI-PMH before using it.  How
would everyone feel about making it mandatory for VO publishing
registries?

(c) The current standard essentially says the Registry Interfaces and
VOResource versions are coupled to each other.  I believe that
coupling isn't technically necessary, as indeed there's no problem
mixing resource records from different schema versions, even if that
schema happened to be VOResource.  Why was that language introduced?
Would anyone object to removing it?

(d) Ray -- do you think your ivo_vor -> oai_dc XSLT might be
(non-normatively) linked from the spec or be otherwise included?

(e) There's a recommendation to use the namespace URI as schema
location in the introduction to 3.  What was the intent of that
recommendation?  Would anyone be cross if I removed it?  I happen to
believe it should be each author's prerogative where they get their
schema files from, in particular as fixing it to ivoa.net makes it
fairly complex to ensure unit tests run with and without a network
connection (don't get me started on XML catalogs).


If you made it till here, I'm sure you'll survive the full text, too.

http://docs.g-vo.org/RegistryInterface.pdf

or, preferably (and you're highly welcome to edit yourself):

https://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface


My plan is to ask around again in about two weeks -- if you already know
that's not going to be enough for you, please holler now.

Thanks,

          Markus