Simple Spectral Access RFC

This document acts as RFC centre for the Simple Spectrum Access Protocol, PR V1.01. Further information on the SSA protocol and associated Spectrum data model can be found on the Collaborative Page for the SSA Interface.

Note that although early SSA implementations included a getCapabilities operation for returning service metadata, specification of this has been deferred to SSA V1.1. The V1.0 specification being reviewed here mentions getCapabilities (and getAvailability) but does not specify the contents of the metadata returned. The older FORMAT=METADATA construct is specified instead. This will eventually be deprecated, but allows SSA V1.0 to go forward immediately while we work to specify these additional operations for V1.1.

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 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.

Discussion about any of the comments or responses should be conducted on the data access layer mailing list, dal@ivoa.net.

Comments

• First sample comment (by BrunoRino): ...
  • Response (by authorname): ...

• Concerning input parameter BAND: In a band range: Is the first parameter expected to be smaller than the second one or can a service accept e.g. band=2000/1000? Is band=/ considered as a valid band range? (by UlrikeStampa)

• • Response by MarkusDolensky:

Yes to the example of the open interval for BAND.

Omitting both values indicates an infinite range which accepts all values.
(sect. 8.7.2)

A specific order is not required except that a list of ranges is processed from left to right and any matching values in any interval shall be returned (logic OR).

• • Response by DougTody:

Since many parameters can accept ranges or range-lists, the detailed semantics of range list parameters are specified once in section 8.7.2 rather than for each parameter. As this section specifies, if numerical ordering of the range-list is required for query processing, it is the responsibility of the service to sort the list, or re-order the range values. In the case of BAND it is clear that such an expression says the same thing regardless of the order in which the elements are given.

• Page 49, Query response example, 3rd line: there is "//" missing in the schema location (by IgorChilingarian)

• • Response by MarkusDolensky: Thanks for spotting Igor.

• Section 4.1.1 expressly states that valid queries don't have to specify all mandatory parameters. Some of them are thus defaulted when missing (i.e. SIZE, FORMAT) but how to deal with POS, BAND and TIME when omitted (especially POS)? Second, does a POS=, (empty list, section 8.7) and a missing POS situation have to be considered as equivalent? In general, how to deal with irrelevant parameters (eg for theoretical spectra)? (by HerveWozniak)

• • Response by DougTody:

This is an important and subtle point. Most parameter values are used only to constrain the query. There is not necessarily any default value if a parameter is not given. If no value is specified for a parameter, e.g., SIZE, then all it means is that it is not used to constrain the query; other parameters must be used to constrain the query instead.

The case of theory data is discussed in section 4.1. A service must support a mandatory parameter, like SIZE, but this does not necessarily mean that the parameter is valid for the data in question. If the query specifies an explicit position (or TIME etc.), and this quantity is undefined for the data in question, then the service should not find any matching data.

The case of something like PARAM=, with no value given, has not been addressed. This would appear to be the same as PARAM="". In general specifying the empty string is not the same as unset, although it may not matter for a parameter such as POS. This needs more thought. In the meantime, it has not been addressed by the current spec.