WD-AccessData-1.0-20140312

[Patrick Dowler]

On 19/03/14 06:43 AM, Petr Skoda wrote:
> So I would add the chapter to both docs stating the BANDNAME is a list of
> symbolic names (strings) of various filter names (including names of
> common X-ray channels) and give example of query with BAND=U,B,V or
> BAND=u,g,r,i,z

I will add the "query by named band" to the use case section of the SIA 
draft, and I can add a BANDNAME section to the query parameters; the 
parameter name has to be different from the one that takes numeric 
values so that it can be described with the right datatype.

We cannot feasibly define the list of possible values, so services will 
need to advertise sane values using some mechanism. As per handling of 
multiple values specified in DALI, BANDNAME would be multivalued, which 
means

BANDNAME=u
BANDNAME=g
BANDNAME=r

would be the correct way to query for multiple values in one request. 
So, look for this in the ext WD.

The service descriptor resource as defined in DataLink can certainly 
enumerate the sensible values for the BANDNAME parameter for a specific 
service. We will have to think about where/how a client gets that 
resource if they want to use an SIA query capability they know the URL 
for. IIRC, SimpleDALRegExt allows one to describe this as well... TBD.

Caveat: it may be that some other objection/issue during the RFC/TCG 
period means we delay including this parameter in 2.0; we are really 
focussed on the datacube use cases but keeping support/semantics usable 
for images as well.

---

As for AccessData, I understand that some data file formats could place 
different bands in different fits extensions (eg) and name them, and the 
"right thing to do" would be to enable a caller to extract that named 
band from the data file. However, there are a lot of fiddly details here 
and the various kinds of operations one can request and what kind of 
file have to be thought through. I would prefer to leave this out of the 
spec for 1.0 and have people just try to implement it and describe the 
parameter/values using the DataLink service descriptor. Since AccessData 
usage is generally occuring "downstream" from some other request, there 
is usually ample opportunity to advertise such custom parameters. If we 
can agree via prototypes using custom params, we can always standardise 
name and semantics in an updated version of AccessData.  Markus might 
chime in that we may realise we don't need to really do that last step 
at all; time will tell.



-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)