IVOA Simple Line Access Protocol v0.2

[Alberto Micol]

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