SSA working draft (fwd)

[Doug Tody]

On Thu, 26 Oct 2006, Steve Allen wrote:
> On Thu 2006-10-26T13:51:31 -0400, Randall Thompson hath writ:
>> The OGIP document would help standardize the unit string. For example,
>> it specifies that the unit string for degrees is "deg" and days is "d".
>> It looks like this syntax was already being followed in the examples though.
>
> Note that the OGIP document was included almost verbatim into
> the approved standard of FITS WCS Paper I.

SSA has also adopted the WCS/OGIP convention for units.  This is
explicitly stated in SDM.  We will include a reference to this in
the protocol document as well, and ensure that the notations used
therein are consistent.


>From rthomp at stsci.edu Thu Oct 26 11:52:27 2006
> > > 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.
> 
> The main reason here is to avoid having to return an error condition
> for what would otherwise be a valid service request. The shorter URL
> is only a side benefit. I'm not sure I understand what you mean by 2
> different "queryData" operations or how this would effect allowing a
> default value. If you expect the service to respond differently for
> these 2 queryData operations it must have another way to distinguish
> them. The protocol already allows a default for VERSION and this
> seems perfectly reasonable.

I guess the point here is that, if a service supports multiple
operations, a client can equally well invoke any operation and it
makes little sense to specify a default operation.  It is as if we
are trying to pretend that we are back in the single operation case
(like SIA 1.0).  I see no problem, once we have services which support
multiple operations, with the service returning an error condition
if the operation to be invoked is not specified.

VERSION is different as it applies to the entire service interface
(all operations).  As the document states, the only reason for making
VERSION optional is to allow the client the option of disabling
explicit version checking by omitting the VERSION parameter.
The default is then the most recent interface version supported by
the service.  The intention is that VERSION would only be omitted
if there are problems, e.g., with unnecessarily stringent version
checking, and the client decides to take responsibility for version
checking/selection and disable it at the service level.

The example I gave of two alternative queryData operations is real
and comes from our discussions of how to add ADQL support into
DAL.  Ultimately we would like to support both parameter-based (as
currently) and syntax-based (ADQL/SQL) query interfaces, both using
a REST interface.  These would be two separate query operations for
the same service interface.  Both would return the same query response
VOTable, and all other interface elements would be the same regardless
of which query operation were used.  (A SOAP interface to the same
service is also possible but that is a separate matter, and SOAP has
its own mechanisms for specifying multiple service operations).
The point is that in general, specifying a default operation is probably
not useful, and it would set a bad precedent to do this for SSA since
we are defining a pattern for future interfaces.

 	- Doug