VOSI11RFC < IVOA

IVOA Web>IvoaGridAndWebServices>VOSI11RFC (2017-05-24, BrianMajor) (raw view)
---++ VOSI v1.1 Proposed Recommendation: Request for Comments

Discussion page for the IVOA VOSI 1.1 Proposed Recommendation.

The lastest VOSI 1.1 Proposed Recommendation can be found at:
   * [[http://www.ivoa.net/documents/VOSI/20161214/][http://www.ivoa.net/documents/VOSI/20161214/]]

---++ Comments from the IVOA Community RFC period: 2015-04-15 - 2015-05-27

---+++ Comments from Mark Taylor

Basically OK. I have a couple of suggestions for change/improvement:
   * *Schema versioning:* 
      * Can this standard make use of the [[http://www.ivoa.net/documents/Notes/XMLVers/][XML Schema Versioning]] Note? In particular, I'd like to see a =version="1.1"= attribute on =tableset= elements returned from tables-1.1 services. 
         * Response by IVOA.BrianMajor (2016-12-14): Good point. I've added the attribute version=1.1 in all top-level documents.
   * *detail parameter:* 
      * I would like to see, alongside =detail=min= , a =detail=max= option. Sometimes the client knows whether it wants/needs the whole tableset at once - it may be that a columnless tableset is no use to it, in which case the current proposal may end up returning a (possibly large) document which it doesn't want. However services (like !VizieR) can't be forced to return the whole tableset if it's huge. So I'd suggest: 
         * _[no detail specification]_ : service decides whether to include column detail or not _(unchanged)_
         * =?detail=min= : service must not include column detail _(unchanged)_
         * =?detail=max= : service may _either_ include all column detail, _or_ fail with a 403 Forbidden
      * I would make use in topcat of a =detail=max= option along these lines if it existed.
      * I still (cf my and Markus's email comments 16 Feb) don't see much value in the 303 redirect.
   * Response by IVOA.BrianMajor (2016-12-14): All these points have been addressed as discussed at the Cape Town interop.
And some minor comments on the text:
   * Sec 3: a rogue backslash is visible in the output of the verbatim'd example element specification =http://some.name.space\#elementName= 
      * Response by IVOA.BrianMajor (2016-12-14): Corrected.
   * Sec 3.1: in the PDF version, the URL =http://www.ivoa.net/xml/VOResource/v1.0= extends off the side of the page (a couple of words elsewhere in the document hang a long way off the right as well). 
      * Response by IVOA.BrianMajor (2016-12-14): Addressed.
   * Sec 4: The table mentions both =ivo://ivoa.net/std/VOSI#tables= and =ivo://ivoa.net/std/VOSI#tables-1.1= standardID values, but the text about the tables endpoint just says "... the value of the standardID attribute must be =ivo://ivoa.net/std/VOSI#tables= ". 
      * Response by IVOA.BrianMajor (2016-12-14): Thanks--the text now says it must be the 1.0 or 1.1 tables URI.
   * Sec 4: "(see example given in section 2.1)" - there is no section 2.1. 
      * Response by IVOA.BrianMajor (2016-12-14): Fixed.
   * Sec 5: Example 1 contains =xsi:type="vs:ParamHTTP"= attributes, where the =vs= namespace is set as =xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.0"= . But the last sentence in section 4 says "this document recommends using the =http://www.ivoa.net/xml/VODataService/v1.1#ParamHTTP= interface type". Is that an inconsistency? Examples 2, 3 and 4 do use the v1.1 namespace (with =vod:= prefix). 
      * Response by IVOA.BrianMajor (2016-12-14): Yes, I think so. All references to VODataService are to v1.1 now. Also, I've updated all examples to use the =vs= namespace as per the recommendation in VODataService "Use of the vs prefix in compliant instance documents is strongly recommended".
-- IVOA.MarkTaylor - 2016-04-19
   * Response by IVOA.BrianMajor (2016-12-14): Thanks for your detailed review.

---++ Implementation and Validators

Please note your implementation or validator in this section.

   $ TOPCAT: A pre-release version of TOPCAT that uses a VOSI-1.1-style tables endpoint (PR-20160413) is available at [[ftp://andromeda.star.bris.ac.uk/pub/star/topcat/pre/topcat-full_vosi11.jar]]. To use it, open the TAP window, point it at a VOSI-1.1 capable service (e.g. !http://www.cadc.hia.nrc.gc.ca/tap) and select from the TAP|Metadata Acquisition menu either "VOSI11-1step" or "VOSI11-2step". It seems to work. -- IVOA.MarkTaylor - 2016-04-19 
      * Updated for =?detail=min/max= hints as agreed in Cape Town -- IVOA.MarkTaylor - 2016-07-11
      * Seems to work for the CADC TAP service =detail=min/max= implementation -- IVOA.MarkTaylor - 2016-10-03

---+++ Comments from Tom McGlynn
---++++ General

This is a pretty simple standard, but I think it is presented in a way that makes it seem more mysterious and difficult than it really is.

After some standard filler in section 1, section 2 jumps into a discussion of the need to build this as a REST standard then in section 3 we talk about how we can get different kinds of metadata.

However we never say what we are talking about... I think this standard desperately needs a paragraph that says something like:

_VOSI provides a standard way to get metadata from VO services which implement it. To use VOSI, a client must first determine a base [VOSI?] URL for the VO service. This is typically provided as a field in the registry entry associated with the service, but other mechanisms may also be used. In this doucument the we use_

_http:/base.host/base/url/_

_as the services base URL. The VOSI protocol defines a set of URLs that can be constructed from the base URL as described below and the required responses that must be provided when these URLs are invoked_.

I'd then recast the GET examples as sothing like:

GET http://base.host/base/url/<strong>availability </strong>

where we typographically separate the base URL and the VOSI suffixes. The text would note this typographic convention.

There may be more complexity here than I realized (see below for my comment on mixing CGI and REST), but the current standard is very hard to understand because there is no root that ties it to the actual services.

With this small addition I think the standard would be much more transparent.

   * Response by IVOA.BrianMajor (2016-12-14): The very first paragraph of section 1 does a decent job of explaining that this specification defines a common way obtaining service metadata. However, I agree that the start of section 2 is abrupt. I have added a short introductory paragraph. As for the determination of URLs for the metadata endpoints, it is not as simple as looking for a constant string (such as 'availability') off a website base URL. Services are free to name these endpoints what they like. The discovery of the URLs for the different metadata reports comes from looking up the particular capability (even for the 'capability' endpoint!) from the services' registry entries.

---++++ Some technical issues

- What about https? Is this supported? All US Federal government sites are expected to go to HTTPS within the next year or so.
   * Response by IVOA.BrianMajor (2016-12-14): There is no specific mention of HTTP vs HTTPS in this document as it is up to each provider to define the endpoint URLs. I don't think mandating a certain protocol for service access should be a part of this document.
- For existing SIA and Cone search interfaces the base URL is often something like:

http://heasarc.gsfc.nasa.gov/cgi-bin/vo/cone/coneGet.pl?table=rosmaster&

If I want to this to support VOSI what is the proper URL to invoke? How do we composite the construction of VOSI URLs with both CGI and rest components? Can the VOSI base URL be different from the base URL used in the DAL query?
   * Response by IVOA.BrianMajor (2016-12-14): 
      * CGI requests within a 'REST' framework are indeed compatible. REST is mainly mentioned to differentiate requests from SOAP web service requests, where service communication is done using XML documents rather than plain HTTP.
      * Yes, the endpoints can be completely different and are defined in the capabilities 'capability' of your service.
---++++ Validation

It seems to me that building a generic VOSI validator to handle just the capabilities and availability responses should be easy and should be required before passing to recommendation. Since I think only TAP services use the tables endpoint and that is supported by TOPCAT and TAPLint already, I don't think that a generic validator need consider that endpoint.
   * Response by IVOA.BrianMajor (2016-12-14): It looks like two validators are now available.
-- IVOA.TomMcGlynn - 2016-05-10
   * Response by IVOA.BrianMajor (2016-12-14): Thanks for your review and comments.

---++ Comments from TCG members during RFC period: 2015-04-15 - 2015-05-27

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

---+++ TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler_ )

---+++ Applications Working Group ( _Pierre Fernique, Tom Donaldson_ )

I approve this document. -- IVOA.PierreFernique - 2017-03-14
---+++ Data Access Layer Working Group ( _François Bonnarel, Marco Molinaro_ )

We approve the document which is a clear and comprehensive specification.

In case the authors still do some little changes we make following optional suggestions

Section 3 = push 3.2 (non - service metadata) as 3. 4 (because it's some addition to "capability", "availaibility" and "tables")

Add an example to section 4 = in order to show how a capability element for VOSI endpoints look like in the registry.

-- IVOA.FrancoisBonnarel - 2017-05-09

-- IVOA.MarcoMolinaro - 2017-05-09

   * Response: Francois, Marco: In the creation of the REC version of this document, I have moved section 3.2 to 3.4 as you suggest. However, even though it is a good idea, I will not add the example because I don't want to make a mistake at this point. -- IVOA.BrianMajor - 2017-05-24

---+++ Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel_ )

I read through the 2016-12-14 version of the document and have no objections. I approve this document.

-- IVOA.MarkCresitelloDittmar - 2017-01-27

---+++ Grid & Web Services Working Group ( _Brian Major, Giuliano Taffoni_ )

I approve this document.

--IVOA.BrianMajor - 2016-12-14

---+++ Registry Working Group ( _Markus Demleitner, Theresa Dower_ )

While IVOA.TomMcGlynn's comment on HTTP/HTTPS was addressed here, section 2 on Interface Bindings still seems to read to me as HTTP-specific. I'd still like to see the HTTP/S agnosticism spelled out if there's an opportunity, but I won't hold up the document on it. Everything looks good to me from a Registry standpoint.

-- IVOA.TheresaDower - 2016-12-15
---+++ Semantics Working Group ( _Mireille Louys, Alberto Accomazzi_ )

I found no contradictory point with any of the Semantics standards, so I approve the document.

-- IVOA.MireilleLouys - 2017-05-11
---+++ Education Interest Group ( _Massimo Ramella, Sudhanshu Barway_ )

---+++ Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick_ )

---+++ Data Curation & Preservation Interest Group ( _Françoise Genova_ )

---+++ Operations Interest Group ( _Tom !McGlynn, Mark Taylor_ )

---+++ Knowledge Discovery in Databases Interest Group ( _George Djorgovski_ )

---+++ Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo_ )

---+++ Standards and Processes Committee ( _Françoise Genova_)

<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Topic revision: r18 - 2017-05-24 - BrianMajor
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema