Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

Proposed changes for 1.1

documentation cleanup/clarification - some copied from the UWS section on TAPImplementationNotes

• Section 2.1.3 HELD status - whilst this might appear to have little utility in current implementations, in future versions where there might be quotas or priorities in the UWS then HELD is a way of expressing within the UWS that the job is accepted in principle, but will not be run until some action (like freeing up some of the quota) is taken.
• It is probably not made clear enough that the initial values of the parameters (and certainly the possible parameter names) are all established during the initial POST that creates the job and in most cases this is how the job should be driven - The ability to set an individual parameter after job creation is an additional capability that the UWS may offer - it should not offer the ability to create new parameters nor delete existing parameters - in this way a client that just creates the job with the initial POST does not "miss" out on setting a crucial parameter. We could make this clearer by removing the ability to set the individual parameter, as I believe that it was added as a "would be nice" feature without a strong use case. There is only one guaranteed way to set a parameter that all UWS services must implement - in the initial POST that creates the job.
• Section 2.2.3.2 & 2.2.3.3, Changing execution duration & destruction time - if a service choses not to implement these features, then the standard is clear that a value of 0 should be returned for the execution duration, but I agree it is not clear what should be returned for the destruction time - in the job schema the DestructionTime element is nillable, so that would be appropriate representation in the job XML - however for the value returned at the resource URL then I agree that there is no description of what should be returned in the case where the UWS never deletes a job - you could return a value far in the future.
• a job can be deleted at any time - it is up to the UWS server side to clean up appropriately
• Although the current wording of the document does not make this clear enough in every case, the intention is that changing the PHASE of the job is a request by the client to the server, and the client sees whether it has been successful by examining the XML returned by the redirect to the URI /{jobs}/(job-id)/. The allowable transitions are shown by the state diagram within the document. TODO: Decide if invalid transitions should be an error
• Attempt to update a parameter on a job that's not PENDING: a 403 [Forbidden] status should be returned
• The text needs updating to say that creating a parameter at any stage other than the initial job creation POST is not allowed.
• Section 2.2.3.1 defines the HTTP response code for an accepted job as 303, but does not say what should happen for a rejected job. It should do (200 plus error document??) -- MarkTaylor - 08 Jun 2011
• The content of the /quote resource is an integer number of seconds (sec 2.1.1), but the content of the uws:quote element is xs:dateTime (schema); this mismatch seems unnecessarily confusing unless there's some rationale I'm missing. -- MarkTaylor - 29 Jun 2011
• Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)

• Filtering of the JobList based on STATUS
• Be more explicit about what parts of job can be altered in the various phases
• directly execute a job passing through PENDING

• add the possibility that a Job is archived at destruction time and therefore there is a new Phase "ARCHIVED" - archived jobs should keep the metadata, but not necessarily the results.
• Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.

Proposed changes for later versions.

• Call-back mechanism - Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).
• blocking resource
• message with the phase
• add possibility to re-run a job from existing job description by copying
• Progress attribute for a Job - have option estimate of percentage completion for a job
• RunID returned in the JobList
• supply a WADL description of UWS rest to allow for automated client generation.
• VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt - with email response http://www.ivoa.net/pipermail/grid/2011-May/002503.html

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

• Quotas - on storage and CPU + ability to query remaining Quota
• Priorities - allow jobs to have settable priorities

Parameters

• enhanced parameter description - how far to go?
• change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Results

• Allow an arbitrary object to be added to the results, much like the JobInfo object.

Authentication and Authorization

• Authentication covered by IVOA SSO spec, but is that easy to use enough?
• Do we want to specify some simple Authorization controls for a job?
• What about having something like OAuth, see http://en.wikipedia.org/wiki/OAuth or http://oauth.net/?
  With that people could reuse their Google or Twitter account.