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)
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.
I appreciate the renumbering of the document into SIAP 1.0 as proposed and I approve this document !
