[SIAv2] query params

[Patrick Dowler]

On 12/05/2013 06:29 AM, Markus Demleitner wrote:
> Dear DAL list,
>
> Sorry for reiterating this, but as noone else has answered so far:
>
> On Mon, Dec 02, 2013 at 10:04:30AM -0800, Patrick Dowler wrote:
>> * Questions *
>>
>> 1. Is there an established use case I am forgetting that says
>> extension parameter support is essential for the initial SIAv2 query
>> interface?
>
> I don't know about "established", but "support for theory data,
> maintaining cross-service discovery" comes to my mind immediately.

SIAv2 query is about querying for empirical image data (2d images and 
datacubes). SimDAL will define it's own query capability.

It is true that past S* services included a convention to specify input 
parameters in the votable and we have always strived to make it feasible 
for implementers to add custom things to standard protocols. In fact, I 
would say this is of paramount importance so that people can implement a 
single service that conforms to the standard *and* provides the custom 
features they need for their specific user community -- that way, the VO 
helps them implement their services rather than is an additional burden.

So: need a mechanism to describe additional query parameters the service 
supports.

>> 2. Do we *really* need this in 2.0? Can we wait for 2.x?
>> - it is true that if we adopt something like the proposed mechanisms
>> for spatial/temporal/spectral query params that this impacts a param
>> description to be developed later
>
> Well, after the experiences of implementing an SSA client that tries
> to do non-cone multi-service queries I keep maintaining that proper
> parameter metadata declaration (at least the valid ranges and an
> valid values for enumerated parameters) is a must even for "standard"
> parameters, at least if there are optional ones or if there are
> optional features for some of them.  Both conditions are met for
> current SIAv2 drafts.

It is much easier on clients if they are told the valid values for 
parameters since S* protocols do not allow them to discover them (in 
principle, TAP does because users could perform "select min(x), max(x) 
..." queries to extract the limits, "group-by" or "distinct" queries for 
enumerated values, etc)...

So: need a way to convey ranges for numeric values and lists of string 
values that will give positive results from the query.

I think we agree that we want this and there is no reason to not 
describe standard params as well as custom ones with the valid values 
metadata.


However, given that WD-DataLink-1.0 includes a section on describing 
service parameters, this is probably not an SIA issue but more general 
and probably belongs in that document; then in SIA we just say how to 
request the parameter metadata.






-- 

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)