IVOA Simple Line Access Protocol v0.2

[Doug Tody]

Hi Alberto -

While I don't think we should rely upon this feature, in general it is
possible that there could be multiple parameter instances regardless of
the protocol, and we could say something about what to do in this case.
Obvious possibilities include unordered OR, disallowed, most recent wins.
Alternatively, the protocol itself could reassemble these as a single
parameter of type scalar, set or array (depending upon the interpretation),
in which case it is a feature of the protocol rather than the parameter
model.  There is also the issue of case sensitivity if we allow multiple
instances of the same parameter.

 	- Doug


On Fri, 10 Feb 2006, Alberto Micol wrote:

>
> Hi Doug,
>
>
>>> Comment: how are lists usually achieved in URLs
>>> --------
>>> I think that the typical way to specify lists in URLs
>>> it is not by using comma separated values, but by repeating
>>> the parameter as many times as necessary.
>>>  [...]
>>> In perl the package CGI.pm, and in python the module cgi,
>>> are used to parse URLs. In both cases they return an array of values
>>> for the input parameter 'param1',
>>> and return a scalar for the input parameter 'param2'.
>
> Well, actually I should have phrased that differently. Forget parsers...
> Those parsers are built that way because that is the natural way a
> HTML form works:
> - radio buttons result in a single value,
> - checkboxes are expanded into multiple occurrences of that input field
> in the url...
> Nothing magic here.
>
>> Of course if a URL parser implements this feature it will work regardless
>> of what we do with the parameter value.  I would be worried though, about
>> relying upon such a URL-specific capability too much.  I doubt if we
>> can assume that this feature (which was news to me) is supported in all
>> URL-processing software, but it would have to be if we were to rely upon
>> this fundamentally in the protocol.  Also it is not quite the same thing
>> as what we have been discussing.  What this really is, is a mechanism for
>> specifying multiple values for the same parameter.  Once we permit that
>> we have to define how to deal with multiple values - does order matter?
>> does a later instance supercede an earlier one?
>
> For checkboxes the order does not matter. Or let me rephrase it,
> for the logical OR order does not matter.
>
>> Should we change SIA
>> to use POS=156.0,POS=20.5?
>
> That's different because the first and the second field are different
> things (ra,dec), and not two possible values for the same thing.
>
>
>> If we use a WSDL (or whatever) interface
>> instead of a URL, can we have still have multiple argument instances with
>> the same semantics?  If we print the parameter value in a table or style
>> sheet what should we output - multiple columns or a single joined value?
>> This seems too complex a feature to rely upon here.  I would rather use
>> protocol-independent tools to parse parameter values, since this approach
>> will work universally.
>
> I agree, but on the other hand if the HTML forms work that way
> there must be good reasons... I would be in favour of
> not inventing yet a new method, but to reuse the same mechanics:
> if a field is repeated then it is of type "checkbox", meaning that
> the field can assume the first value (logical) OR the second value OR ... 
> etc.
> I find it quite natural, and protocol independent.
> Indeed in XML that would be the way:
>
> <VALUES>
> <VALUE>First</VALUE>
> <VALUE>Second</VALUE>
> </VALUES>
>
> no?
>
> I guess I should go look at the ADQL specs ...
>
>
>>> PS: It remains unclear to me whether x:y includes or not the 
>>> extreme(s)...?
>>> 
>> 
>> I think if people had to guess they would guess that the values are 
>> included,
>> so that is the most natural definition.
>
> OK thanks, I thought so.
>
> Alberto