TAP 1.0: Substantive comments.

[Doug Tody]

On Mon, 31 Aug 2009, Patrick Dowler wrote:

>> Just to clarify with an example.  We might have parameters
>>
>>     UPLOAD=mytable,inline:mytable;yourtable,http://your.host/table.xml
>>     mytable=<?XML...><VOTABLE>...</VOTABLE>
>>
>> [where mytable would likely be populated as a file upload but this
>> is not required.]
>>
>> This uploads two tables, yourtable which is specified through an
>> external URL, and mytable which is uploaded as part of the query.
>
> Since one could use a VOSpace URI (vos://) as the second value in an UPLOAD,
> it looks like we are basically talking about defining a URI scheme for
> "inline".... so then we are down to Tom's point about making sure it doesn't
> collide with anything.

Yes.  It is like a file URL but the storage context is the runtime
service protocol context.

> A detail question: in interacting with an async (UWS-based) service, one can
> set params on the server side in a series of POSTs, starting with the POST
> that creates the job. That is, one can create the job, then POST various
> params u pto the point where one POSTs PHASE=RUN to start the job. Once you
> start a job you can no longer modify it. So, if one is to use
>
> UPLOAD=mytable_name,inline:mytable_content
>
> would the inline content have to be delivered in the same POST as the UPLOAD
> param that connects the TAP table name with the content? I would assume this
> is required but just checking that this is what we mean.

Ok I guess params could be set in this way but I would expect that most
commonly all the params would be specified at once.  What we really
have is a parameter set which is input to the service operation once
it runs.

For the file attachment inline content the most natural thing would
be to include the file in with the POST containing the UPLOAD param,
however it is not clear that we need to require this.

The UWS mechanism probably just wants to collect all the parameters in
some generic fashion without knowing anything about them.  When the
service operation is finally executed at RUN time, that is when the
service-specific code would want to run to sort out and validate the
parameters and process things like the upload.  So we might just
process the multipart attachment into a general file-like object
in the operation runtime context (maybe stored as a special type of
parameter?) and leave it to the RUN-time code to process the table
upload into the DBMS.  In that case the parameter collection phase
can be fully generic, and we again separate the service-specific
semantics from the general mechanism.  All the parameter-collection
code need do is check for duplicate parameters, URL decoding, any
other generic processing, meanwhile composing the final paramset.

My conclusion is we don't need to say anything special about UPLOAD
where UWS is concerned.

 	- Doug