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)...? >> >
OK thanks, I thought so.
Alberto Received on 2006-02-10Z17:42:43