IVOA Simple Line Access Protocol v0.2

[Doug Tody]

On Fri, 10 Feb 2006, Alberto Micol wrote:
> Question:
> ---------
> Ranges are useful also for strings, not only for numeric values.
> In this case, whatever metacharacter is chosen, we need to know
> how to escape it. I'm thinking of those cases where such
> metacharacter is actually part of the original string.
>
> What would be the escape sequence in this case?

This is a good question.  This has been a nasty problem with many systems
(the unix shells for example).  Probably we need to define a simple
escape mechanism to be used within parameter values, and if necessary
this may have to be escaped second-order in whatever context the overall
parameter value string appears in, a URL in our immediate case here.
Perhaps all that is needed is to define the string delimiter and a
mechanism to escape it within a string element within the parameter value.

An important general point for these issues concerning parameter values
(also relevant for the issue below) is that while we want this to work
well for URLs, the matter of encoding parameter values and passing
them through unchanged from client to server is more general and should
work well regardless of the protocol use to pass the parameter value.
Hence we don't want to come up with a solution which relies too much upon
the details of any single transmission protocol.


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

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?  Should we change SIA
to use POS=156.0,POS=20.5?  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.


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

 	- Doug