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

See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?

Proposed changes for 1.1

changes that do not break existing client implementations

• Filtering of the JobList based on STATUS
• Be more explicit about what parts of job can be altered in the various phases
• Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
• directly execute a job passing through PENDING

changes that might break clients

• 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.
• 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).
• Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.

Proposed changes for later versions.

• 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

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?