| |
| META TOPICPARENT |
name="SiaInterface" |
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.1.
Review period: 2009 May 25 – 2009 June 22
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.
* 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.
* 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.
* 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)
* 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.
* 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?
* 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.
* 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.
* 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.
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)
Data Curation & Preservation (Bob Hanisch) |
