[SIAv2] query params

[Arnold Rots]

So, what do you gain by this change over using a pure STC-S expression
that allows you to put the entire query into a single string expression and
provides the flexibility of seamless future extension?

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------



On Wed, Nov 13, 2013 at 6:05 PM, Patrick Dowler <
patrick.dowler at nrc-cnrc.gc.ca> wrote:

>
> The effect of the proposal is to fold SIZE into the POS parameter by
> having geometry values instead of a separate SIZE parameter, so SIZE would
> go away. This is consistent with having ranges for BAND and TIME instead of
> a single value and a "width" parameter.
>
> It also removes the use of STC-S from query parameters (with the intent of
> also not using STC-S in AccessData and eventually not including coordinate
> metadata in ADQL values either as it is generally agreed that conflating
> data and metadata in that way was a bad idea).
>
> In those geometry values, we could well define both RANGE and BOX types as
> they serve different purposes; they behave differently but predictably at
> the poles.
>
> I have preserved the range syntax from SSA and predecessors, but there is
> no support for "range lists": when developing DALI we explicitly discussed
> lists of values are agreed that multiple values would be done with multiple
> parameter=value pairs instead.
>
> Hope that helps to clarify it.
>
>
> Pat
>
>
> On 11/13/2013 02:08 PM, Douglas Tody wrote:
>
>> The proposal here appears to be that POS,SIZE,BAND,TIME,POL, and in
>> particular POS, could be generalized sufficiently so that we can drop
>> the REGION parameter (REGION being an STC-S string that an optionally
>> replace POS,SIZE,BAND,TIME,POL as the specify the filter term).  I will
>> ignore the issue of REGION for the moment, but agree strongly that
>> having things already broken out as in POS,SIZE,BAND,TIME,POL makes
>> service implementation simpler, and extends well to capabilities such as
>> range-list values.
>>
>
> --
>
> Patrick Dowler
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9A 2L9
>
> 250-363-0044 (office) 250-363-0045 (fax)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20131114/e9c6c379/attachment.html>