vos:group vs. uws:JobInfo

[Paul Harrison]

Hi,

The UWS schema is only a representation of job control metadata - it was a deliberate decision or UWS not to try to prescribe in any way what the job actually did. Indeed, in early drafts the schema did not contain any reference to "parameters" at all. However, it was recognised that for a majority of use cases within the IVOA that adding simple name/value parameters would be common to DAL services, so it was worthwhile adding these to the base schema, even though they only represented a subset of the total kinds of JDL that UWS was intended to cover.

On 2010-08 -16, at 16:54, Matthew Graham wrote:

> Hi Paul,
> 
> Rereading the UWS spec, I realise that the exact format of a request is not defined anywhere. I had assumed, following standard REST practices, that a job would be initiated by a POST of the appropriate resource representation, i.e. a <uws:job> document, although there also existed a mapping from a HTML form to this for the case of simple key-value parameters. Otherwise it seems a little confusing to me that you would be using different resources to start, report, and potentially modify the same job.
> 
I think that UWS does follow "standard" REST practices, but let's face it there is no REST standard so we can all have different opinions about exactly what REST means, especially the relationship with CRUD (which is not mentioned by Fielding). Here is a link http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/ to someone with pretty much the same interpretation as that used by UWS - For me, what makes UWS RESTy is that the initial create of the job is a POST (not a PUT which would require some direct representation of the job resource) to a different resource URL (the Job list URL) conceptually altering the list by adding a new job.  This POST creates a new resource URL (the job) that is then used to modify the new resource, so that the report and modification of a job happen for a single URL.  Note also that the XML returned from the job resource is only a representation of the job resource, and that is perfectly acceptable for the resource to have more than one representation, and conceptually the default initial representation of a job resource in UWS is a null, as the server is free to choose execution time etc. - This allows the initial POST that creates the job to be free to focus on defining what the job does rather than how it is controlled.

> 	Cheers,
> 
> 	Matthew
> 
> 
> 
> On Aug 16, 2010, at 4:37 AM, Paul Harrison wrote:
> 
>> 
>> On 2010-08 -13, at 18:50, Matthew Graham wrote:
>> 
>>> Hi Paul,
>>> 
>>> Thanks for the swift response - this certainly helps the discussion. 
>>> 
>>> Is it your recommendation that any service which uses UWS specifically states what its JDL is? Is there a suitable format for this for validation, etc? In VOSpace 2.0, I have assumed that the <uws:parameters> define the job since there is no initial POST - what is posted is the full XML representation of the Job resource, e.g.:
>> 
>> OK - now I see what you are doing - As far as the UWS specification goes, I think that the initial POST can be anything, and I guess that the using the a document conforming to the uws:job schema is ok, though I think a rather confusing, and possibly limiting choice. I would personally use a specific vospace schema that does what you want directly as the JDL, rather than trying to squeeze this into the allowable spaces in the UWS job description (and incidentally the schema "any" definition in the UWS schema does mean that any <vos:transfer> needs to be in a <uws:jobInfo> element).
>> 
>> Cheers,
>> 	Paul.
>>> 
>>> <uws:job xsi:schemaLocation="http://www.ivoa.net/xml/UWS/v1.0
>>> UWS.xsd "
>>>   xmlns:uws="
>>> http://www.ivoa.net/xml/UWS/v1.0
>>> "
>>> xmlns:xlink="
>>> http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>>> ">
>>> <uws:jobId/>
>>> <uws:ownerId xsi:nil="true"/>
>>> <uws:phase>RUN<uws:phase/>
>>> <uws:startTime xsi:nil="true"/>
>>> <uws:endTime xsi:nil="true"/>
>>> <uws:executionDuration>0</executionDuration>
>>> <uws:destruction xsi:nil="true"/>
>>> <uws:parameters>
>>>   <uws:parameter id="target">vos://nvo.caltech!vospace/mydata1</uws:parameter>
>>>   <uws:parameter id="direction">vos://nvo.caltech!vospace/mydata2</uws:parameter>
>>>   <uws:parameter id="keepBytes">false</uws:parameter>
>>> </uws:parameters>
>>> <uws:results/>
>>> </uws:job>
>>> 
>>> or have I misread UWS?
>>> 	Cheers,
>>> 	Matthew
>>> 
>> 
>> 
> 

Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank