[SIAv2] upload

Douglas Tody dtody at nrao.edu
Tue Mar 11 12:58:32 PDT 2014


On Fri, 7 Mar 2014, Patrick Dowler wrote:

> OK, not much discussion on this so I will answer with my CADC hat on since we 
> have implemented upload in services and have clients (Our AdvancedSearch web 
> UI that queries our TAP service).

Actually I did post on this earlier but got no response, so I copy the
message again here (see below).

The question to be considered is if we really need this complex
general mechanism to reference the fields of a table if all want is
multiple values for a (usally non-table structured) parameter.
The simplest approach is to merely upload the list of values as a
block of text, one value per row of text, with the same formatting
as specified for the parameter in question.  Usually there is only
one just list per request, but multiple such simple uploads per
request are possible.

The votable-based mechanism could also be useful, but is overkill
for most simple use cases.

 	- Doug


Date: Wed, 29 Jan 2014 10:48:42 -0700 (MST)
From: Douglas Tody <dtody at nrao.edu>
Subject: Re: [SIAv2] upload

Another possibility not mentioned would be to keep it simple, e.g., we
have UPLOAD=<name>,<uri> as always, where some content is tagged by the
<name>.  But then we have a reference like POS=@<name>, and the content
of the referenced file/text upload is a simple list of values for POS,
one value per line of text.  No votable in this case since all we really
have is a list of values replacing a single value (unless the parameter
in question actually requires a table as the value, as with TAP).  The
syntax required is defined by the parameter for which we are uploading a
list of values.

A more general mechanism to pull stuff out of a table is also possible,
but not necessary to solve the problem of uploading a list of values for
a parameter.

This would work well for parameters like POS, BAND, TIME, where we often
want a list of values (it also works for any arbitrary parameter).  If
we wanted to combine POS,BAND,TIME,POL then that would argue for keeping
a REGION parameter of some sort.


More information about the dal mailing list