IVOA Support Interfaces (VOSI) RFC (Version 1.0)This document is a "Request for Comment" (RFC) for the Proposed Recommendation "IVOA Support Interfaces V1.0" (also known as VOSI). The latest version of the specification (11-03-2010) can be found at: http://www.ivoa.net/Documents/VOSI/20101206/ IVOA Review Period: 9 Apr 2010 - 14 May 2010. TCG Review Period: 8 Dec 2010 - 7 Jan 2011 This specification describes the minimum required interface to participate in the IVOA as a web service. It is an essential component of the TAP specification and so any TAP implementation also serves as a VOSI implementation. 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 that 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. Additional discussion about any of the comments or responses can be conducted on the GWS WG mailing list, grid@ivoa.net. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from the community
Comments from TCG during TCG Review (8 Dec 2010 to 7 Jan 2011)Applications (Tom McGlynn, Mark Taylor)Thanks for addressing my comments about document structure. There remain a couple of typos:
Data Access Layer (Patrick Dowler, Mike Fitzpatrick)Approved. -- IVOA.Patrick.Dowler - 2011-03-01Data Model (Mireille Louys, JesusSalgado)Approved. -- MireilleLouys 2011-05-04Grid&Web Sevices (Matthew Graham, Paul Harrison)I approve this document. -- MatthewGraham - 08 Dec 2010 The current version of the document mandates that all VO services provide the availability and capabilities interfaces. Following discussion at the Nara Interop closing plenary session, it was agreed that this statement should be amended in the VOSI document to read: It is agreed that IVOA "services" standards previous to VOSI may not be forced to retrospectively implement VOSI (although that should be encouraged). Nonetheless, all new IVOA "services" standards (or updated existing ones) must enforce the VOSI implementation. -- MatthewGraham - 12 Dec 2010Registry (Gretchen Greene, Pierre Le Sidaner)Registry WG approves with following comments: comments reflect on the abstract statement...web service requires? later in section 3.1 service should provide. which is it? i see your comments later, but perhaps the abstract can reflect the clarification you've stated above for new IVOA services standards section 3.2 please move the non-service metadata section to last would be good to clarify the registry and vosi getCapability does this come from services? request that this is explicitly written This document should mention WADL as a possible descriptor for REST service. Preference not to require client to require SOAP service binding for VOSI endpoint to SOAP service. VOSI can simply be URL based different from web service. Terminology is confusing as described in the Capability description of the document. It may help to clarify service capability vs resource capability further and what the hierarchy of xml elements are in each case. Example http://voparis-srv.obspm.fr/srv/tap-titan_temperature/capabilities Request more detailed examples: a second example for SIA should be done classical param of SIA 1.0 (sky position + ROI) extended parameters (time, band) that should be taken from STC (inclusion of schema) or Observation DM -- GretchenGreene - 08 March 2011 | ||||||||
Changed: | ||||||||
< < | I've responded to all of these in the latest version. In particular, an appendix has been added to clarify the service capability vs resource capability issue. | |||||||
> > | I've responded to all of these in the latest version. In particular, an appendix has been added to clarify the service capability vs resource capability issue. | |||||||
Added: | ||||||||
> > | Regarding the SOAP service binding, sec. 2 does state "This standard requires the REST binding of VOSI even when applied to services that otherwise use SOAP". The SOAP binding was removed from the previous version (see "Changes since WD-20081030". | |||||||
Regarding the more detailed examples request, Ray comments: The SIA example kept the SIA capability minimal so as to highlight the format features of VOSI. How to format an SIA capability which all its use of extended parameters and STC coverage is more something for the SimpleDALRegExt document.
-- MatthewGraham - 05 May 2011
Semantics (Sebastien Derriere, Norman Gray)Document approved, just a few minor typos to be fixed in the final version : p5, the reference to section 2.2.1 of [1] should be section 2.2.1 of [12], i.e. VOResource and not SOAP In section 4, 1st table, typo in endpoint: capabilties -> capabilities Section 5, in the last comment of the first XML example, it is not the interface returning this document, but the interface returning availbility.VOEvent (Rob Seaman, Roy Williams)Approved (in the absence of objection from Roy). -- RobSeaman - 14 March 2011Standard and Processes (Francoise Genova)Data Curation & Preservation (Alberto Accommazzi)KDD (Giuseppe Longo)Theory (Herve Wozniak, Claudio Gheller)I approve. Just s small comment. In the sentence (end of Sect. 1) "Once a user discovers data and services of interest, she will want to use engage them in an analysis process.", why the user cannot be a man?TCG (Christophe Arviset, Severin Gaudet)I approve the document, seconding Matthew's comments discussed and agreed at the Nara closing plenary. A couple of minor editing remarks to be taken into account:
<--
|