RFC initiated for Simple Spectral Access protocol

[Doug Tody]

Hi Randy -

Thanks much for the very careful and thorough read-through.

> SSAP V1.01 Comments/typos
>
> - Section 1.3.4 states that more information on error responses is
> given in section 7.4. Section 7.4 actually discusses data retrieval
> errors. Although its referenced in 7.4, the real information is found
> in section 8.10.

Good point, 8.10 is a better reference.  We will change this.


> - Section 1.4.1 states "VOTable is preferred if only one format is
> supported".  I would suggest not preferring one data format over another
> and leaving it to the data providers to decide. For an "archival" SSA
> service, which is the more likely type of service to offer only one
> format, FITS may be a better choice.

This may be a controversial point, but my opinion is that VOTable may
prove to be a better choice as an interchange format (not necessarily for
archive storage) for metadata-rich VO spectra, especially since an SSA
client already has to support VOTable for queries.  Astronomy software is
already adapting to support VOTable.  I suspect that most new spectral
services and client software will prefer to support VOTable over FITS.
I think it is useful to suggest a format for those who will only implement
one format.  If there is sufficient disagreement we can reconsider the
point though.


> - Section 2.4.2 mentions that "the full creation type can be more than one
> of these operations, for example, both projection and filtered...". Does
> this imply that the dataset creation type metadata value can be a list? Is
> this true in general (i.e., that metadata can be defined as multiple
> (comma separated) values)?

Yes, the intention was that the creation type could be a list.
In general a parameter can be a list, range, or range-list, but only if
the specification says so.

It would be nice to simplify this and have the values be fixed, but the
concern was that, since CreationType describes what was done to the data,
it might be necessary to describe independent operations.  For example a
"mosaic" may or may not recompute the pixel values.  "filtered" always
means that the pixel (sample) values were recomputed in some fashion.


> - Section 3.1 typo Add an "an" before "explicit parameterized operation".

Will fix.


> - Section 4.1.2 typo - recommended parameters are indicated in the tables
> by "REC", not "REQ" as stated.

Will fix.

> - Section 4.1.2, 2nd sentence after table "The spatial resolution is
> important as it is usually comparable to the diameter of the spectral
> aperture on the sky...".  I don't think this is why spatial resolution
> is important. Note the wording in the SDM paper (section 4.6.3) "the
> spatial resolution may be useful to know if it exceeds the aperture size;
> the default is to assume it is equal to the aperture size."

Reporting the spatial resolution in the dataset metadata is a different
matter than using it for a query parameter.  I agree though that we should
consider if this can be phrased better.  What the text was trying to say
is that, for most data, the spatial resolution is *probably* comparable
to the aperture, and for the purposes of a query they can be considered
similar, but that the actual values will be returned in the dataset
metadata and can be used to refine the query further if necessary.
The point here is merely to simplify the interface.

> - Section 4.1.2.2 typo? defines spectral resolving power as dW/W, while
> the SDM paper section 4.6.3 defines it as W/dW, as does the table in
> 4.1.2. I assume the text just needs to be corrected.

Will fix; this was a typo and is incorrect.

> - Section 4.1.2.10/4.1.2.11 - FLUXCALIB and WAVECALIB are true/false
> parameters defined as "Specifies whether only flux/wavelength calibrated
> data is to be found".  It's not clear to me from the wording whether
> a value of "FALSE" means return only uncalibrated data or return both
> calibrated AND uncalibrated data.  Perhaps this can be clarified. There
> are really 3 logical possibilities, return calibrated, uncalibrated,
> or both. I assume the default is to return both.

Will rephrase.  Yes, the default is to return both calibrated and
uncalibrated data, with the detailed metadata describing the situation.

> - Section 4.2.6.2/4.2.6.3 shows metadata names in a different font, but
> some were listed with the same font as the text which makes it confusing
> (i.e., "Collection", "Creator", and "PublisherDID" ). Also, I believe,
> the first reference to "CreatorDID" should really be "DatasetID".

Agree it is inconsistent; will fix.

The CreatorDID is the identifier assigned by the dataset Creator;
it is like a serial number and is not the ADS (for example) "Dataset
Identifier".  Will clarify.

> - Section 8.10 3rd paragraph add "the" before "senses described below".

Will fix.

> - General, The SDM paper states that UTYPE's and UCD's are case
> insensitive but I didn't see this mentioned in the SSAP paper. There
> was some confusion about this for the SIAP UCDs. If it's not already
> mentioned somewhere, perhaps it would help avoid confusion to state this
> in the SSAP paper as well.

Good suggestion.

	- Doug