Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: . This version includes comments from the TCG during the RFC period.

The original RFC document is:

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04

Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

I agree this is a fairly major departure for a 1.1 document, and it's worth noting. I've added a section in the introduction noting the removal of SOAP as a recommendation and addition of RegTAP plus encouragement of other future standards. I also changed "version 1" to "version 1.0" where I'd missed it, and am reviewing places where we may want to say "version" of the document as a whole rather than specification of a schema itself, a carryover from prior versions of the document. Thank you. -- TheresaDower - 2017-08-22

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Editorial comments :

section 1.2 : has a citation and links to the VOResource specification, but no link to the IVOA identifiers
specification , which would help to identify the related documents

section 2.2
OAI-PMH decuments --> documents

Appendix B 'The VORegistry Schema' reads xmlns:vm="" which is not defined in the . ? is it a typo, remains from previous versions?

In the "References" section,

Readibility :

The document explains the actions planned for managing the network of VO registries, but some guide lines for the new comer to grasp all the interconnected concepts: VOResource, Services, Data collections, etc. should be given. A map, graph of the Registry ecosystem, as didactically described in the Proposed Endorsed Note "Discovering data collections Within Services" could be added in this spec and in VOResource as well, or at least included at the top of the Registry wiki pages.

I approve the document, and hope this request for a didactic add-on to the set of Registry related documents would be considered positively.

-- MireilleLouys - 2017-08-24

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2017-10-23 - TheresaDower
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback