SSA working draft (fwd)

[Randall Thompson]

Doug Tody wrote:

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


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.

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

>
>
>     - Doug

Randy