IVOA Simple Line Access Protocol v0.2

[Doug Tody]

Hi Jesus -

I agree with this analysis completely.  In particular, the basic
functionality of AND and OR is implicit in the way parameters work.
The extra complexity of being able to distinguish between GT and GE is
not worth it here, as one can just change the value by 1 for an integer
parameter, while the distinction is meaningless for a floating value
since you always have to fold in some sort of error function in any case.
(Also by implication, the equality test for a floating point parameter
assumes the server is smart enough to fold in an error function, hence
the floating equality test is actually a small range test).

Probably what we have here is enough to get started.  If we wanted to
get fancy, some advanced features to consider might include:

    o	The use of {} to group list elements (needed for a list of lists
        or small structs).
    o	Define some character other than the list delimiter (comma) for
    	qualifiers such as "source" or units.
    o	An indirection operator, to fetch a large list value from somewhere,
        e.g., from a URL, from POST data, etc.

All of these have come up before with similar range lists in other contexts.
However, except possibly for qualifiers we can leave these out for now
and still add them later if a use case comes up which needs them.

	- Doug


On Fri, 10 Feb 2006, 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
>
>
> ESAC Science Archive Team
> e-mail: Jesus.Salgado at sciops.esa.int
> Tel + 34 91 8131271
>
> European Space Agency/European Space Astronomy Centre
> VILLAFRANCA Satellites Tracking Station
> P.O. Box 50727
> E-28080 Villafranca del Castillo
> MADRID - SPAIN
>