[SIAv2] upload

[Patrick Dowler]

Just addressing the referencing here...

On 11/03/14 05:02 AM, Markus Demleitner wrote:
> Right.  But if you agree with (1)..(3) above and then start figuring
> out how metadata for your compound, polymorphic parameters would look
> like... shiver.
>
> Again, apologies for being obnoxious, but I do think experience from
> past protocols with alphabet soup parameters has shown we
> shouldn't have started with them, and we certainly should stop now.

It looks to me like you *really* dislike the references (POL=$foo.blah) 
becaue one cannot describe the parameter correctly (a la the service 
descriptor stuff in DataLink). I could counter with "well, once you 
resolve the symbol after the $, you do get a double, integer, or 
whatever" so I'm not sure it is fatal. But fair enough, it is also 
indirect and you cannot immediately evaluate parameters and parse the 
supplied values according to statically typed constraints.

So, Markus would argue that to support UPLOAD, every service parameter 
FOO would have an associated FOO_REF parameter that says where (in an 
ploaded resource) to get the value(s). This would apply equally to all 
the query params and custom params really must (should?) follow the same 
style. As a result, one could do something like:

UPLOAD=foo,http://example.com/mytable.xml
POS_REF=foo.col1

which would work if col1 of mytable.xml held positions (circles, ranges, 
or polygons). In the more usual case of tables with coords in separate 
columns, one would have to use something like:

POS_REF=CIRCLE foo.RA foo.DEC 0.1

Using *_REF for references would remove the need for $symbol and would 
leave the vanilla parameters to be strictly typed.

Can we have a general show of hands/votes for POS_REF vs POS=$foo?? Or 
at least another opinion :-)


-- 

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)