TWiki
>
IVOA Web
>
IvoaDAL
>
SiaInterface
>
SiaV1RFC
(revision 7) (raw view)
Edit
Attach
---+ Simple Image Access Protocol specification V1.0: Request for Comments This document will act as *RFC* centre for the [[http://www.ivoa.net/Documents/PR/DAL/PR-SIA-1.1-20090521.html][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 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. * 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) ---+++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". <br/> <!-- * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup -->
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r31
|
r9
<
r8
<
r7
<
r6
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r7 - 2009-06-18
-
GuyRixon
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
Applications
Data Access Layer
Data Model
Distributed Services & Protocols
Registry
Semantics
Interest Groups
Data Curation
Education
Knowledge Discovery
High Energy
Operations
Radio Astronomy
Solar System
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback