Simple Image Access Protocol specification V1.0: Request for Comments

This document will act as RFC centre for the 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 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

* 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)

Approved.

Data Model (Mireille Louys, AnitaRichards)

I approve the document. MireilleLouys

Grid&Web Sevices (Matthew Graham, Paul Harrison)

I approve this document. MatthewGraham

Registry (Ray Plante, Aurelien Stebe)

Approved!

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 ! -- SebastienDerriere

VOEvent (Rob Seaman, Alasdair Allan)

Approved - 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) -- approved

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 !


Topic revision: r31 - 2009-11-11 - RayPlante
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback