[SIAv2] query params

[Douglas Tody]

Another example of why being clear about list-valued parameters is
useful is automated input parameter set verification.  Each input
parameter for the service has a type attribute and this includes
specification of whether multiple values or a list value is permitted
for that parameter (ditto for datatype, range specification, etc.).  If
we formalize the attributes of each parameter in this way then all the
input processing, including basic error detection, can be generic,
regardless of the service type or the specific request parameters.  We
could even extend list-valued to permit specification of the list via
UPLOAD and have all this handled transparently by the generic input
processing.   - Doug


On Wed, 13 Nov 2013, Douglas Tody wrote:

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