UWS POST PHASE=RUN

[Paul Harrison]

On 2014-11 -03, at 16:14, Matthew Graham <mjg at cacr.caltech.edu> wrote:

> Hi,
> 
> On Nov 3, 2014, at 4:29 AM, Paul Harrison wrote:
> 
>>> 
>>>    * When an XML document is submitted as single parameter, how must it be stored in the UWS service: as one parameter (with byReference=true) or as some individual parameters which has been extracted from the XML document?
>> 
>> I think that it should be stored as a single “parameter” - there should be no attempt by the generic UWS to interpret the document.
>> 
>> I think that it would probably be a good convention that if the initial POST has a application/x-www-form-urlencoded encoding, then the UWS can assume that the parameter/value pair mechanism can be used.
> 
> Except that the best practices is that application/x-www-form-urlencoded encoding is used with all POSTs, irrespective if it is a single XML document or parameterized. So you seem to be saying that if an XML document is submitted as a single "parameter" then some alternate encoding should be specified - would you care to suggest which one?
> 

I don’t think that it is necessary that POSTs should *all* be application/x-www-form-urlencoded. -  it is the recommendation for for job control parameters (i.e. the phase, destruction time etc) but the JDL (what the job actually does as its business logic) is separate, and UWS says that can be a generic POST - What this boils down to in the HTTP protocol is the value of the Content-Type header in the POST - consequently any mime type is legal and so the generic UWS can use "application/x-www-form-urlencoded" (and equally "multipart/form-data") to recognise when the typical DAL (and normal HTML form) name/value parameter mechanism is being used as a JDL and then be able to process multiple parameters - as opposed to the case where the JDL is an opaque blob (as far as the generic UWS client/server is concerned) and the JDL can be only accessed as a single opaque “parameter”, which I was suggesting be named “JDL” by convention - though the name does not really matter that much as there is only one “parameter” in this case, and there is the under-documented “isPost” attribute on the parameter element in the UWS schema that is supposed to indicate this case.

So in answer to your specific question if the JDL is a generic XML document then application/xml could be used as the content type, and the generic UWS client and server would do no “parameter extraction” from such a document. I think that there is a “grey area” in this XML based JDL scenario (which I think is what Grégory was pointing out) in that it is possible that the JDL could simply use the parameters element from the UWS schema. I have to admit that I was not thinking of doing this explicitly when writing the UWS specification - the UWS schema was intended as a description of the state of the job, rather than a language for creating the job.

We could say that if the POST content type was application/xml and the uws:parameters element was used as the JDL then the UWS server was expected to parse out the parameters from the XML content and interpret them separately - I think that this was under-specified in UWS 1.0 and UWS 1.1 could make this point clearer. I do feel, however,  that the UWS should leave open the “generic” JDL option, that is not necessarily a “parameterised” JDL.

One of the most important design aims concerning the JDL and the generic UWS API and JobSummary is that it should be possible for a generic UWS client to rerun a job by querying an existing job - without “understanding" what the job does. In the original conception of the JDL just being an opaque blob, it was simply a case of the server storing the blob and then returning it to the client to resubmit - however, things have become a little more complex once the parameterisation was included and it is allowed that individual parameters can have their value changed after submission, but I think that generic UWS clients/servers can still manage this with a little care, even if the parsing out into separate parameters might require some transformation into “byReference” parameters (particularly in the case of multipart/form-data).

Paul.