SSA-1.1 and Spectrum-1.1 Proposed Recommendation: Request for Comments

This document serves as the RFC center for the Proposed Recommendation entitled "Simple Spectral Access, Version 1.1". At the same time the Spectrum Data model document has been updated in order to correct minor inconsitencies in notation with respect to the SSA protocol standard document ( Utypes mispell, UCD, Fits keywords completed.)

Latest version of SSA can be found at:

• http://www.ivoa.net/Documents/SSA/20110706/

Latest version of Spectrum Data Model can be found at:

• http://www.ivoa.net/internal/IVOA/IVOADMSpectraWP/PR-SpectrumDM-1.1-20110318.pdf

Additional discussion about any of the comments or responses can be conducted on the Data Access Layer mailing list, dal@ivoa.net and on the Data Model mailing list, dm@ivoa.net However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

Reference Interoperable Implementations

Implementations Validators

RFC Review Period: 20 Apr 2011 - 17 May 2011

TCG Review Period: 01 June 2011 - 28 June 2011

Comments from the IVOA Community during RFC period: 20 Apr 2011 - 17 May 2011

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that 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.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments from TCG member during the TCG Review Period: 01 June 2011 - 28 June 2011

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)

Comments on SpectrumDM 1.1 - ChristopheArviset 2011-06-07

All my comments are mainly editorial or related to document formatting. I'll be happy to approve SpectrumDM 1.1 once they've been addressed.

[Section 1 Introduction and Motivation] This section should already clearly indicate the reason for SpectrumDM 1.1, which is mainly for corrections coming from feedback implementation and does not represent any fundamental changes wrt the existing Recommended SpectrumDM 1.03 released on 29 October 2007. It should also indicate its "pairing" with SSAP 1.1.

[Section 1.1 Change log] This section should also clearly indicate the Recommended SpectrumDM 1.03 released on 29 October 2007

[Section 1.2 IVOA Architecture] Last paragraph should either be rewritten to better reflect the relationship between SpectrumDM 1.03, SpectrumDM 1.1 and the upcoming SpectrumDM 1.2 or should be removed (one could argue why we need a reference to SpectrumDM 1.2 in the SpectrumDM 1.1 document?).

[References] The references section should be udpated with latest version of standards and should contain all IVOA standards introduced in Section 1.2

Various formatting issues:

• Blank pages that should probably be removed: 18, 22, 66, 81
• Landscape pages that are cut on the border: 19, 20, 21, 23, 24, 25, 26
• Pages cut on the border due to too long text: 40, 41, 55, 57

Comments on SSAP 1.1 - ChristopheArviset 2011-06-07

All my comments are mainly editorial. I'll be happy to approve SSAP 1.1 once they've been addressed.

[Page 2] Reference to VOSI should be updated as it has now become a REC

[Section 1] Introduction As agreed, together with the IVOA Architecture Diagram, some text should explain the relationship between SSAP and the other IVOA Standards present on that diagram.

The SSAP text used for the IVOA Architecture document could probably be inserted as is:

Simple Spectra Access Protocol (SSAP) defines a uniform interface to remotely discover and access one dimensional spectrum coming from data and metadata collections. SSAP is based on the Spectrum Data Model (itself making reference to the CharDM) that is capable of describing most tabular spectrophotometric data, including time series and spectral energy distributions (SEDs) as well as 1-D spectra. SSAP can be used from VO applications to access the associated spectrum resources. As with most of the IVOA Data Access Protocols, SSAP makes use of VOTable for metadata exchange, STC, UCD, Utypes and Units for metadata description. An SSAP service is to be registered into the VO Registry, using the associated registry standards (in particular Resource Metadata, VOResource and SimpleDALRegExt specifically for Data Access Protocols such as SSAP). Once registered, an SSAP service will get a unique IVOA Resource Identifier. Furthermore, an SSAP service should be registered with its supported interfaces through the VOSI standard.

Applications Working Group (Tom Mcglynn, Mark Taylor)

Approved - TomMcGlynn 2011-06-12

(but fix or remove reference in SSA Section 8.10.2 which contains the text "see also section 8.10.2" -- MarkTaylor - 04 Jul 2011)

Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)

Approved - PatrickDowler 2011-06-01

Data Model Working Group (Jesus Salgado, Omar Laurino)

Approved - JesusSalgado 2011-07-01

Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )

Approved - AndreasWicenec

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

Approved with comments - GretchenGreene 2011-09-19

1.3.2 Parameters Suggest version should be defined via VOSI not in the protocol definition (twice describe and moreover it's not mandatory)

2.1 Dataset and Data Collection possbily add link to the VODataService document where all voservice concepts defined same comment on 4.1.2.14 COLLECTION

2.4 Virtual data do not understand this sentence, it is a capability of cutout. This should be decribe in vosi or regex It's more important in the case of cutout or slice cut of spectral cube.

2.5.1 Data Source artificial : Artificial or simulated data. This is similar to theory data but need not be based on a physical model, and is often used for testing purposes. do not understand the interest of this item : the main purpose is the input parameter that make a difference between simulated and observational data. Why don't we simply keep simulated or theoretical data

2.7 Services, Interfaces, and Protocols is the meaning of this paragraph that it's a HTTP protocol ?

2.8 Dataset Identifiers Why reinventing the wheel ? There is an IVOA docume "IVOA Identifiers" If it need some evolution. Then it should be in this document not in SSA.

2.9 Provenance No mention of DM provenance or VOResource

2.10 Data Association Should be described in the registry, same for all protocols

3.2 Methods & Protocols Does anyone want to implement SSAP in SOAP ? May be say also REST ? the 3.3.1 GetCapabilities and 3.3.3 GetAvailability can mention that this is under definition in the VOSI document and make a ref at the end to the proposed recommendation version at least ref http://www.ivoa.net/Documents/VOSI/20101206/PR-VOSI-1.0-20101206.pdf instead of http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/VOSupport InterfacesMandatory-0.26 . pd f at the end of the document

3.3.2 StageData you mention " is not planned for SSA V1.0", may be it's 1.1

4.1.1.5 FORMAT "If FORMAT is omitted, FORMAT=ALL should be assumed" don't you think it verbosity will increase really the size of the output. What not default to votable ?

8.10.2 Overflow Previous point made, ? understanding the new changes in case of overflow no client yet redo the query with maxrec don't you think the service should answer Overflow an produce a query response containing the maximum number of records. Then the client could at once give to the user the first N response and inform that there is an overflow. is it still compliant with 4.1.2.16 MAXREC " A service should typically have a fairly small default MAXREC, provided to improve the query response time, and a large upper limit on MAXREC, provided to enable large queries." that mean that the service will all the time answer an overflow and will not provide data ?

Semantics Working Group (Sebastien Derriere, Norman Gray)

VOEvent Working Group (Matthew Graham, Roy Williams)

Data Curation & Preservation Interest Group (Alberto Accomazzi)

Knowledge Discovery in Databases Interest Group (Giuseppe Longo)

Theory Interest Group (Herve Wozniak, Franck Le Petit)

Approved - HerveWozniak 2011-07-04

Standards and Processes Committee (Francoise Genova)