Difference: UWS11RFC (6 vs. 7)

UWS v1.1 Proposed Recommendation: Request for Comments

Public discussion page for the IVOA UWS 1.1 Proposed Recommendation.

The latest version of the UWS Specification can be found at:

Reference Interoperable Implementations

CDS / GAVO Implementation (Gregory Mantelet)

VO Paris Implementation (Mathieu Servillat)

CADC Implementation (Pat Dowler)

Implementations Validators

No implementation validators for UWS 1.1, though CADC (and others?) have UWS 1.0 validators that still pass:

• CADC UWS 1.0 Validator: OpenCADC cadcTestUWS

• taplint TAP validator within stilts does non-exhaustive validation of the UWS v1.0 functionality of a TAP service: job submission, lifecycle tracking, deletion, job document parsing etc. See UWS Stage. If someone can point me at a running UWS 1.1-compliant TAP service (minimum: WAIT-blocking and job documents labelled version='1.1' ) I'll try to update the validation for it. -- MarkTaylor - 2015-07-03

RFC Review Period: 2015-06-30 - 2015-08-18

Comments from the IVOA Community during RFC period: 2015-06-30 - 2015-08-18

Comments from MarkTaylor

(Still) a good clearly written document. One or two minor comments/suggestions:

* Notation: I don't understand the usage of curly and round brackets in referencing URL path elements. For instance in sec 2.1.11 I see: "/{jobs}/{job-id}/parameters/(parameter-name)", and in sec 2.2: "/(jobs)/(jobid)", and in sec 2.2.1.1: "/{jobs}/(job-id)". Are () and {} doing different, ahem, jobs here? If not, can you just pick one or the other?

• • there is no significance in the different types of braces - I have made them all curly.
• Sec 1.3: "an XML document (e.g. ADQL, CEA [harrison05])" - is it anachronistic to refer to ADQL in this context since post-ADQL-2.0 there is no ADQL/X representation?
  • I think you are right - I have removed it
• Sec 2.1: A count indicator ("1") is missing from the Job-Owner link in the UML diagram
  • you are right - and quote should be 0..1
• Sec 2.1.3: The phases "HELD", "SUSPENDED" and "ARCHIVED" do not appear in the diagram.
  • I had not added these in the past as I thought it would complicate the diagram, as the conditions for transition into those states are more complex - you are probably right that they should be included though, and I have produced a version with them all in.
• Sec 2.2: "future versions of this document will add other bindings such as SOAP." Really?
  • highly unlikely - I have made the statement less precise about which binding may be added.
• Sec 2.2: "an non-existant job id" -> "a non-existent job-id"
  • done
• Sec 2.2.1.1: "it should not return a response (i.e. block)" is a bit ambiguous. Prefer "it should not return a response (i.e. it should block)"?
  • done
• Sec 2.2.1.1: "/{jobs}/(job-id)?WAIT&PHASE=QUEUED": I think it has to be "WAIT=<value>" not just "WAIT"?
  • done
• Sec 4.2: "ADQL [1] can serve as a JDL." - bibliography referencing is wrong.
  • corrected
• Sec 4.3: "Call it CEA v2 to distinguish it from CEA v1 as currently maintained by AstroGrid." - it's a bit anachronistic.
  • changed wording to make it clear that AstroGrid is no longer active
• Sec 4.3: "The JDL in CEA v2 is similar to that in CEA v1 It is a formal ..." - missing full stop
  • done
• Sec 4.3: "the emerging XForms technology" - is it still emerging?
  • not really - have updated wording.
• Schema: version attribute to be made optional? (see schema evolution discussion)
  • done in latest version of document and schema

Comments from WalterLandry

Regarding the new job query capability in Sec 2.2.2.1, it feels like
we are creating yet another query syntax with new keywords. To be
concrete, I would change the examples to

• /{jobs}?QUERY=PHASE=EXECUTING
• /{jobs}?QUERY=STARTTIME>2014-09-10T10:01:02.000
• /{jobs}?QUERY=TOP+100

• /{jobs}?QUERY=(PHASE=EXECUTING+OR+PHASE=COMPLETED+OR+PHASE=SUSPENDED)+AND+STARTTIME>2014-09-10+ORDER+BY+ENDTIME

Reply by PaulHarrison

Whilst I would normally be a strong advocate of trying to reuse existing syntax and not do re-invention, in this case the filtering capability is not intended to be a full query language for jobs. I think that your suggestions start to introduce the full query language approach which has the following disadvantages

1. More effort has to be made in defining the query language than the current standard does - e.g. TOP in ADQL does not imply any ordering - by using the "keyword" style filtering that the current document specifies exactly what LAST means - so to be consistent with ADQL the "query language" should be something like /{jobs}?QUERY=TOP+100+ORDER+BY+STARTTIME+DES
2. There is a greater burden on the implementors to do the query parsing.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->