UWS 1.1 comments

[Paul Harrison]

On 2011-10 -20, at 09:31, Patrick Dowler wrote:

> On 2011-10-20 00:06:12 Paul Harrison wrote:
>> As already said you can start the job with all its parameters in one step
>> already in V1.0 or you can do it in several steps using feedback from the
>> server to fine tune the job metadata. Also note that you are not allowed
>> to create new parameters after the initial POST, only potentially change
>> their values - and again this is an optional feature for the server to
>> support - the only place that the server must support setting parameter
>> values is in the initial POST.
> 
> Paul - can you point to the section of the UWS spec that prohibits one to POST 
> new params to the job or the parameters child resource? I naively would think 
> that a POST to /joblist/<jobid> would modify the job and a POST to 
> /joblist/<jobid>/parameters would modify the parameter list (eg add something 
> to it). A POST to /joblist/<jobid>/parameters/foo would modify the existing 
> parameter named foo and fail (404) if it was not there (not create it). This 
> would all be standard REST style, imo.
> 
> Thoughts?
> 
> 
> PS-In my opinion, changes to a spec that allow something previously not 
> allowed or otherwise relax constraints are in principle backwards compatible, 
> but if the spec really says that POST FOO=bar /joblist/job must modify an 
> existing param named FOO, that is problematic.


It was not explicit in the original 1.0 specification (the wording just said that you may "update a parameter"), but I thought that the discussion from the last Interop had come up with the recommendation that it be made clear that parameter creation could only happen at job creation time and so I had added "(but not create)" it to the latest draft http://volute.googlecode.com/svn/trunk/projects/grid/uws/doc/UWS.html#ResultsList2 (sec 2.1.11) as one of the "uncontroversial" changes. The thinking behind it was that as parameter creation was part of the JDL which is outside the scope of UWS then there could not be a generalized client that could create parameters in the parameter list.

The whole area or being able to set the parameters in the parameter list is actually optional and given that the original standard did not explicitly allow or disallow it, so I guess the decision can still go either way - I take it that you are using this feature....


Paul.