IVOA Simple Line Access Protocol v0.2

[Alberto Micol]

Dear Range and List aficionados,

A Question and a Comment:

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?


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. That is, taking Jesus'
example:

 > param1=[3:5],[7:)&param2=(1000,3000]

it is preferred to write:

param1=[3:5]&param1=[7:)&param2=(1000,3000]

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

Obviously, we would all agree that it is useful to reuse existing
conventions/parsers not to have to reinvent the wheel.

Also, such approach will allow to reuse the comma for other  
applications,
like the suggested:

wavelength=w1:w2,source

where 'source' is an attribute and not an element of the list.

Thanks,

Alberto
PS: It remains unclear to me whether x:y includes or not the extreme 
(s)...?


On Feb 10, 2006, at 11:34, Jesus J. Salgado wrote:

> Hi Doug,
>
> Your approach looks good. Pedro and I were thinking in a similar
> approach but using brackets and parenthesis to define domains (in the
> same way that is done in standard calculus). For example, using a
> notation close to yours:
>
> param=[3:5)
>
> (values in range from 3 to 5, including 3 but not including 5)
>
> param=[3:5],[7:)
>
> (values in range from 3 to 5 including both OR range from 7 to  
> infinite
> including 7)
>
> As the "," means "OR" in the final SQL sentence, we have been thinking
> if other logical operators are needed, but probably the current
> definition is enough, as the "AND" is used more often for the
> combination of queries for different parameters, e.g.
>
> param1=[3:5],[7:)&param2=(1000,3000]
>
> means:
>
> (param1 values in range from 3 to 5 including both [OR] range from  
> 7 to
> infinite including 7) [AND] (param2 values in range from 1000 to 3000
> including 3000)
>
> Depending on the type of variable and the rounding error, the  
> difference
> between open and close ranges might be more or less relevant; so
> probably, as your approach is easier to parse, we can adopt your
> definition for the wavelength range in the SLAP.
>
> Best Regards,
> Jesus
>
>
> On Wed, 2006-02-08 at 17:48, Doug Tody wrote:
>> A simple approach to range lists which requires only a slight  
>> departure
>> from what is currently done in SIA (POS) and proposed for SSA is  
>> to keep
>> "," as the list delimiter but switch to another metacharacter, ":"  
>> perhaps,
>> for ranges.  Then we have
>>
>>      param = x				equality
>>      param = x:y				closed range
>>      param = x:				open range
>>      param = x,y				list
>>      param = x,a:b,y			range list
>>  	etc.
>>
>> For example, for a list of wavelength ranges (one of our SIA cube  
>> access
>> use cases) we would have
>>
>>      wavelength=w1a:w1b,w2a:w2b,w3a:w3b,...
>>
>> This approach can also be used for simple abstract datatypes, e.g.,
>>
>>      wavelength=w1:w2,source
>>
>> could specify wavelength in vacuum in the rest frame of the source.
>>
>> The semantics would be defined on a per-parameter basis.  One  
>> advantage of
>> this approach is that the semantics are defined by the parameter  
>> and hence
>> are protocol independent; the same string can be passed through  
>> from the
>> client to the server regardless of the protocol used (URL, WSDL,  
>> parameter
>> file, Java RMI, XML RPC, etc.).  The atomic nature of encoded  
>> parameter
>> values helps here.  Once again, for a fully general approach we  
>> can use
>> a language approach instead (ADQL) so we want to keep this fairly  
>> simple.
>> Quite a lot can be done with a simple parameter-based interface  
>> however.
>>
>>  	- Doug
> -- 
> Jesus J. Salgado
>