IVOA Simple Line Access Protocol v0.2

[Doug Tody]

Sorry, it should have occurred to me to include this thought in the mail
I just sent.

Our convention is to define a URL instance as a <base-URL> plus a
concatenated parameter list serialized in URL-format.

What if the same parameter occurs in both the base-URL and in the
parameter list?  I have already seen this in actual service instances.
For example, there is one site which includes a FORMAT parameter in the
base-URL, I suppose because the implementation is more general than the
registered instance, which is supposed to be a finding chart service
which returns only graphics images.  If I come along and pose a query to
this service with a FORMAT parameter, this particular service returns
an error even if I ask for a graphics image back, probably because the
implementation does not permit multiple values of the same parameter.
This service is actually broken because FORMAT has to be an allowed
parameter in any SIA query, but the correct interpretation in this case
is that whatever the client specifies overrides the base-URL, i.e.,
most recent wins.

All I can conclude at this point is that these semantics are too complex
to rely upon (plus we need service verification tools!).

 	- Doug




On Fri, 10 Feb 2006, Doug Tody wrote:

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