SSA working draft (fwd)

[Doug Tody]

Hi Randy -

On Thu, 26 Oct 2006, Randall Thompson wrote:
> Hi Doug,
>   Having valid examples would be a nice "detail" to have
> available before beginning test implementations. I have
> always found information in the examples that is not
> contained elsewhere.

I agree, it would be useful to have updated examples and we will provide
those in the next document update.

> In any case, here are a few more
> comments. Some may also be considered details, but I
> did leave out comments regarding typos and references
> to non-existent sections.

For the VOTable query response examples I should probably have said
"feature" rather than detail.  When it comes to the actual interface,
we should be looking at the details.


> UNITS - Would it be useful to follow the units conventions
> described in the OGIP 93-001 document as is done in the
> SDM paper?

For the most part in the protocol the units are fixed, and this is noted
in the document; the protocol fixes the units in Char for example, whereas
the SDM does not.  If units were allowed to vary, we would use the same
convention as in the SDM.


> REQUEST - I would still like to see a default value
> (e.g., "queryData") defined for REQUEST. I suspect the
> queryData operation will comprise the majority of SSA
> requests and defining a default value  should not conflict
> with adding any additional values in the future.
> This would allow SSA requests to be as simple as:
> http://www.myvo.org/ssa?POS=22.4,17.2
> By not allowing a default, service providers will presumably
> be expected to return some sort of annoying error message
> if REQUEST is not included.

Then what happens if we later provide two different queryData
operations, e.g., one which is parameter based, and one which uses
ADQL?  It is a simple thing to explicitly specify the operation
to be executed, so it is hard to make a case for excluding this
merely to shorten the URL.  Similarly for VERSION, it is best to
explicitly specify the version of the protocol the client assumes,
to ensure that version mismatches do not occur (this is also good
for the service logs).  Also, although most usage of SSA will likely
emphasize the queryData operation, we are establishing a pattern for
future services for how to support multi-operation services with
a REST interface (based on OpenGIS/WMS), and future services may
support larger interfaces with more operations.


> APERTURE - It appears this parameter has been redefined
> and no longer applies to existing spectral data. If it is referring
> to a numerical extraction slit however, a rectangular shape
> would still seem a reasonable option.

Right: the APERTURE parameter was redefined, and is now only used for
dynamic spectral extraction.  It was just too confusing to overloap
APERTURE, and use it for both queries and spectral extraction, plus
for queries there was some overlap of APERTURE and SPATRES - for most
spectra these are comparable, or at least comparable enough for a
discovery query where only a rough value is required.  The exception
is when the aperture is much larger than the spatial resolution,
however this is rare for 1-D spectra, and can be handled by query
refinement on the client side using the characterization metadata,
which defines the actual observational aperture, and footprint on
the sky in the case of a slit spectrum.


> COMPRESS - Are there any restrictions in the types of
> comrpessions to be allowed (e.g., is hcompress)?

SSA only supports protocol-level compression, e.g., gzip of an entire
VOTable.  A future SIA may also support dataset-level compression
such as HCOMPRESS.  There is a FITS convention (ZIMAGE) for tiled
compression which supports this, however it has not yet been widely
adopted.  This is more of a data format option than a protocol option
however.

 	- Doug