[SIAv2] query params

[Douglas Tody]

On Wed, 13 Nov 2013, Patrick Dowler wrote:

> The effect of the proposal is to fold SIZE into the POS parameter by having 
> geometry values instead of a separate SIZE parameter, so SIZE would go away. 
> This is consistent with having ranges for BAND and TIME instead of a single 
> value and a "width" parameter.

Off hand I don't see a problem with folding SIZE into POS.


> It also removes the use of STC-S from query parameters (with the intent of 
> also not using STC-S in AccessData and eventually not including coordinate 
> metadata in ADQL values either as it is generally agreed that conflating data 
> and metadata in that way was a bad idea).
>
> In those geometry values, we could well define both RANGE and BOX types as 
> they serve different purposes; they behave differently but predictably at the 
> poles.
>
> I have preserved the range syntax from SSA and predecessors, but there is no 
> support for "range lists": when developing DALI we explicitly discussed lists 
> of values are agreed that multiple values would be done with multiple 
> parameter=value pairs instead.

We agreed to support multiple params at the level of the HTTP protocol,
since this is a feature of HTTP.  However that doesn't mean we cannot
support list values for parameters as well.  It could be quite awkward
to try input a large list or array as many parameter instances in HTTP.
This also breaks the parameter set model that some of us use.  In our
implementation for example, we have some HTTP-specific code that pulls
parameters from HTTP and builds a parameter set.  All further service
processing is independent of the use of HTTP for input.  Multiple
instances of parameters don't work well with the parameter set paradigm;
list values, arrays, etc. are trivial.  If we do something like echo
the input parameters in an INFO in the request response, it will be
a whole lot more readable and unambiguous if param=<list> is used.

What is means is that we can permit multiple parameter instances at the
HTTP level as DALI specifies, but if the service parameter being
accumulated is list-valued, a list is built up during input parameter
processing.  Alternatively a list value could be input directly.  I see
no reason to drop support for list-valued parameters.  We can still
support the multiple instance feature at the HTTP level.

 	- Doug


> Hope that helps to clarify it.
>
>
> Pat
>
> On 11/13/2013 02:08 PM, Douglas Tody wrote:
>> The proposal here appears to be that POS,SIZE,BAND,TIME,POL, and in
>> particular POS, could be generalized sufficiently so that we can drop
>> the REGION parameter (REGION being an STC-S string that an optionally
>> replace POS,SIZE,BAND,TIME,POL as the specify the filter term).  I will
>> ignore the issue of REGION for the moment, but agree strongly that
>> having things already broken out as in POS,SIZE,BAND,TIME,POL makes
>> service implementation simpler, and extends well to capabilities such as
>> range-list values.
>
> -- 
>
> Patrick Dowler
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9A 2L9
>
> 250-363-0044 (office) 250-363-0045 (fax)
>