(r29) SiaV1RFC < IVOA

IVOA Web>IvoaDAL>SiaInterface>SiaV1RFC (revision 29) (raw view)~~EditAttach~~
---+ Simple Image Access Protocol specification V1.0: Request for Comments

This document will act as *RFC* centre for the [[http://www.ivoa.net/Documents/SIA/20091008/PR-SIA-1.0-20091008.html][Simple Image Access Protocol specification]] Proposed Recommendation v1.0. 

IVOA RFC period   : 2009 May 25  2009 June 22

TCG Review period : 2009 Oct 15 - 2009 Nov 06

In order to add a comment to the document, please edit this page and add your comment to the list below (include your TWiki.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. Please be aware that SIAP V1 has been a _de facto_ standard for some time so suggestions for change might be deferred to SIAP V2.

Discussions about any of the comments or responses should be conducted on the DAL mailing list, dal@ivoa.net.

---

---++ Comments from the community

   * Sample comment by TWiki.JoeBloggs
      * Response (by TWiki.AloysiusBickerstaffe)

* comment by PatrickDowler

The examples for error documents (eg end of section 4) use VOTable 1.1 or earlier directly embedded text; maybe clarify that this is VOTable version dependent; the reference is to the latest VOTable spec.

   - Response by DougTody.  Agreed, we should mention that VOTable 1.1 or
     later should be used, but the exact form of the INFO serialization may
     depend upon the VOTable version.

* comment by PatrickDowler

Spectral Bandpass metadata: The response should have a FIELD with ucd=VOX:BandPass_Unit. Why not just use the unit attribute in the FIELD(s) describing the values? I think this is the only place in the VO with this non-standard unit handling. Impact: this field is not required so removing it won't make services non-compliant; it may break applications that literally interpret the SIA spec and do not consider the VOTable spec fully.

   - Response by DougTody.  This makes the unit specification part of the data model and independent of the representation (VOTable in this case).  Spectrum does the same thing for another example.  One wants to do this when a unit is shared by several fields of a data model.  In any case, this would be an interface change which is ruled out for legacy SIA V1.0.

* comment by PatrickDowler

FIELD vs PARAM: for any of the "should have a FIELD with..." is it a valid (equivalent) interpretation to use a PARAM instead if the value is constant? This is service-specific, but applicable to many of the recommended FIELDs, which may be constant. Impact: If this was explicitly allowed (or document just clarified that it is allowed) this gives services more freedom to reduce the size of the output VOTable but would not effect compliance of existing services; it would require applications or VOTable-reading libraries to be more flexible (e.g. correct) in their treatment of FIELD/PARAM.

   - Response by DougTody.  The convention in all the DAL interfaces has always been that a PARAM can be used if the value of the FIELD is constant for the entire table.  Nonetheless it is simpler to refer to FIELDS in metadata descriptions.  The problem could be addressed by merely adding a separate statement that PARAM may be used instead of FIELD if the value is constant for the entire table (as we do in other specifications).

* Comment by GuyRixon

The wording of section 4.1 is confusing. The "base URL" as described may not actually conform to RFC3986 - is an empty query string valid? - and certainly looks odd. It would be simpler to say that:
all the queries go to the same web resource and are distinguished by their query string; there may be query parameters fixed by the service that are the same for all queries; there may be other parameters that vary between queries but are not defined by SIAP; SIAP defines the following parameters. The details of what is registered can be moved to the registration section (which is what I would be reading when writing registration code, not section 4.1)

   - Response by DougTody.  This is a base URL, not a valid URL (or
   web resource if you prefer).  It is merely used to construct an
   actual URL, by appending parameters, as the specification states.
   The baseURL alone has no usage in SIA or other DAL interfaces.
   Note this is well-established tradition for these services, and
   is captured in all our specifications and in the registry metadata.

* Comment by GuyRixon

The technical note on projections uses the undefined terms RASZ and DECSZ.

* Comment by GuyRixon

The description of the INTERSECT parameter has this sentence: "If the client requires a more precise measure, the spatial intersection a target image with the ROI may be computed precisely using the WCS metadata returned in the output VOtable." It would be better to say explicitly that this is something that the client must do. Currently, it looks like the server does it for some undefined stimulus.

   - Response by DougTody.  The point is that the service is allowed to merely
     approximate the search region calculation, and indeed should err on the
     side of including data (this is true in general of all elements of the
     discovery query).  Accurate metadata is returned however, and the client
     can refine the query result if it requires greater precision.  The
     document tries to make this point clear but perhaps a more explicit
     wording is warranted.

* Comment by GuyRixon

In section4.2, subsection "Access Metadata", please specify the semantics of VOX:Image_AccessRefTTL rather than implying them. E.g., what happens after the TTL expires - 404 error?; can the accref be reused after the TTL?

   - Response by DougTody.  Good point, although I think this feature
     has been rarely used (if ever) in current implementations.
     The intention was that a error response would be returned hence
     the URL would no longer be valid after the TTL period.  How to return
     such an error response is not clear - either an SIA protocol error
     (VOTable INFO) or an HTTP error could be used: the protocol requires
     clients to be able to deal with either.  Some service implementations
     for example implement the acref URL as a call to a "getData" service
     operation (to generate virtual data), and there are many types of
     errors which might occur when generating virtual data.  If the URL
     resolves to a simple file access then an HTTP error might be returned
     instead.  I suggest that we leave this unspecified for SIA V1 as it
     has never been an issue (but it is important for a client to be
     prepared to accept either form of error response).

* Comment by GuyRixon

The MIME-type for the returns, stated in section 4.2, is not what we agreed in Strasbourg. The standard should recommend the newer form (can't remember what that was OTTOMH) but allow the old form for established services.

   - Response by DougTody.  The MIME type specified is consistent with what
     we already have in SCS and SSA, which are IVOA standards.  One could
     argue that we remain consistent with these standards for now, and
     instead refine the MIME type only for TAP and future interfaces.
     If there is sufficient call to eliminate the parameterized MIME type,
     the MIME type recommended must be "text/xml" to be consistent with the
     original SIA specification and with current practice (else all of our
     existing services are invalidated).

* Comment by GuyRixon

The first paragraph of section 5 could be clarified. It takes several readings to confirm that this is just what happens when an HTTP GET goes to an accref. Calling it a "web method" is unhelpful. In standard, technical terms you are describing the _representation_ of the _resource_ for which the accref is the URI.

   - Response by DougTody.  Maybe.  As with all the DAL interfaces
     the logical service interface is defined in terms of service
     operations, not explicitly in terms of HTTP.  Hence while a URL
     is used for the acref to maximize implementation flexibility,
     logically what we have is the getImage service operation (some
     service implementations literally implement things this way as
     I noted above).  We also need to be careful as in principle SIA
     has always permitted the acref URL to reference a protocol other
     than HTTP (although I don't know of any actual case where this
     feature has been used).

* Comment by GuyRixon

Splitting the description of registration between section 6.2 and appendix B makes it hard to read. Neither section stands alone. There should be a reference to the document defining the schema. The registration material would be clearer if the description of the registered, base URL was moved from section 4.1.

* Comment by GuyRixon

The registration section should mandate VOSI availability and VOSI capability endpoints in the service. These might be "should" requirements to allow older services to remain compliant.

   - Response by DougTody.  This would be nice, but as neither has yet been
     specified nor implemented in any existing service, it would hold up
     the standard unduely to address this now.  I agree that it should be
     a standard part of future interfaces.

* Comment by DougTody

The following errata was pointed out by Jonathan Fay:

"by" used instead of "be"...

"Note that when it contains extra GET arguments, the base URL ends in an
ampersand, &; if there are no extra arguments, then it ends in a question
mark, ?. In addition if there are any extra arguments in the base URL, then
they must not "by" [Should be "be"] one of the standard service
arguments defined below in this section."

---

---++ Comments from the TCG during the normal RFC period (25 May 2009 - 22 June 2009)

---+++Applications (Tom !McGlynn, Mark Taylor)

---+++Data Access Layer (Keith Noddle, Jesus Salgado)

---+++Data Model (Mireille Louys, AnitaRichards)

---+++Grid&Web Sevices (Matthew Graham, Paul Harrison)

---+++Registry (Ray Plante, Aurelien Stebe)

---+++Semantics (Sebastien Derriere, Norman Gray)

---+++VOEvent (Rob Seaman, Alasdair Allan)

---+++VO Query Language (Pedro Osuna, Yuji Shirasaki)

---+++VOTable (François Ochsenbein)

---+++Standard and Processes (Francoise Genova)

---+++Astro RG (Masatoshi Ohishi)

I would trust comments by the experts, and would say, "I approve".

---+++Data Curation & Preservation (Bob Hanisch)

My only comment regards item 3 in Section 2.  As was discussed recently for TAP, the data access protocol should not mandate the registration of services in the registry.  The "must" should be a "should".  With this revision I would approve the document.

---+++Theory (Herve Wozniak, Claudio Gheller)

---+++TCG (ChristopheArviset, Severin Gaudet)

I approve the document.

As agreed at the last Strasbourg Interop, the document should be renamed PR-SIAP-1.0-20090522.html to stick to SIAP 1.0 and to avoid to create confusion with "SIAP v1.1".

---

---++ Final Approval from the TCG  (15/10/2009 - 06/11/2009)

---+++Applications (Tom !McGlynn, Mark Taylor)
Approved.

---+++Data Access Layer (Keith Noddle, Jesus Salgado)

---+++Data Model (Mireille Louys, AnitaRichards)
I approve the document. IVOA.MireilleLouys

---+++Grid&Web Sevices (Matthew Graham, Paul Harrison)

I approve this document.
IVOA.MatthewGraham

---+++Registry (Ray Plante, Aurelien Stebe)

---+++Semantics (Sebastien Derriere, Norman Gray)

Approved. Good to see the de facto standard properly defined. UCD usage will probably be an issue in future SIAP versions ! -- IVOA.SebastienDerriere

---+++VOEvent (Rob Seaman, Alasdair Allan)

Approved - IVOA.RobSeaman

---+++VO Query Language (Pedro Osuna, Yuji Shirasaki)

I approve.


---+++VOTable (François Ochsenbein)
Looks compliant with VOTable-1.2 definitions (example of section 6.1 was checked against latest schema  2009-09-29) -- <b>approved</b>

---+++Standard and Processes (Francoise Genova)

Approved

---+++Astro RG (Masatoshi Ohishi)

Approved.

---+++Data Curation & Preservation (Bob Hanisch)

Approved.

---+++Theory (Herve Wozniak, Claudio Gheller)

Approved.

---+++TCG (ChristopheArviset, Severin Gaudet)

I appreciate the renumbering of the document into SIAP 1.0  as proposed and I approve this document !




<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Topic revision: r29 - 2009-11-11 - FrancoiseGenova
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
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema