[SIAv2] query params

[Patrick Dowler]

On 11/18/2013 04:54 AM, Markus Demleitner wrote:
> I will not dispute it would be great to have more complex types
> represented as such in DAL protocols and -- in what I believe is a
> necessary consequence -- VOTables in general.

Yes, I agree that in the longer term if adopted these should also result 
in new VOTable datatype(s). The xtype usage for TAP went only part way 
and is more complex than just defining the datatype(s) would have been. 
Still, that mechanism is there now and it could also be used for this 
sort of thing.

In either case, I am not particularly fond of defining these datatypes 
in a specific DAL protocol document. If the DM-WG were to claim this is 
within the mandate of DM and include it in the scope of a current (or 
new) document, they would not see any resistence from DAL. As I recall, 
vo-dml includes some core reusable things...

>I'm not entirely sure
> the world is ready for this (inspecting actual SSA responses has not
> been encouraging), but perhaps all that's this is telling us is that
> we, as people defining the standards, have an obligation to provide
> reference implementations in Java, Python (I volunteer for this) and
> PHP as a minimum.

I can provide a java library

> Be that as it may, my point is that ad-hoccing syntax (even if there
> is precedence) is *not* a good way to define types (as again
> witnessed by SSA; in particular see custom service parameters, where
> data providers clearly were at a loss to see whatever type model was
> implicit in SSA, and there's no way to communicate which what type is)

It is true that SSA (and this topic in SIA-2.0) implies some types but 
does not really come out and say it... but that is also true of ADQL-2.0 
and is something that needs to be rectified. Still, we have been able to 
stumble along with TAP  :-)


-- 

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)