(r28) UWS11RFC < IVOA

IVOA Web>IvoaGridAndWebServices>UWS11RFC (revision 28) (raw view)~~EditAttach~~
---++ 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:
   * [[http://www.ivoa.net/documents/UWS/][http://www.ivoa.net/documents/UWS/]] (30th November)

---+++ Reference Interoperable Implementations

Would the implementors of the UWS 1.1 specification please add details; or, please remove your implementation from this list if not correct.

---++++ CDS / GAVO Implementation (Grégory Mantelet)

<div id="_mcePaste">The CDS/GAVO UWSLibrary is a Java framework designed to create and customize as easily as possible a UWS service. The last stable version of this library - targeting the UWS 1.0 standard - is available at <a target="_blank" href="http://cdsportal.u-strasbg.fr/uwstuto">http://cdsportal.u-strasbg.fr/uwstuto</a> and the sources on Github at <a target="_blank" href="https://github.com/gmantele/taplib">https://github.com/gmantele/taplib</a>.</div>

<div id="_mcePaste">The implementation of the UWS 1.1 standard in this library seems now to be complete. Sources are available on the <a target="_blank" href="https://github.com/gmantele/taplib/tree/uws1.1" title="branch uws1.1">branch _uws1.1_ </a> of Github. Since UWS 1.1 is still a _Proposed Recommendation_, no stable version of the library is for the moment released. However, a Beta version is available at <a target="_blank" href="http://cdsportal.u-strasbg.fr/uwstuto/uws1.1Note.html">http://cdsportal.u-strasbg.fr/uwstuto/uws1.1Note</a>. In addition, the <a target="_blank" href="http://cdsportal.u-strasbg.fr/uwstuto/basic/timers">demo provided on this web-site</a> has also been upgraded to UWS 1.1.</div>

<div id="_mcePaste"> *Please, report any bug and/or missing feature you may found while testing it!* </div>

<div id="_mcePaste">This beta version supports the following UWS1.1 features:</div>

<div id="_mcePaste">

   * <span style="background-color: transparent;"> _The new execution phase: ARCHIVED._ </span> 
      * <span style="background-color: transparent;">since no standard way is described in the UWS1.1 document to set a job into this phase, the library proposes 3 policies:</span> 
         * <span style="background-color: transparent;">never (at destruction the job is just destroyed completely),</span>
         * <span style="background-color: transparent;">when the job reaches the destructionTime</span>
         * <span style="background-color: transparent;">and whenever the job is asked to be destroyed for the first time.</span>
      * <span style="background-color: transparent;">an archived job can be destroyed as any other job</span>
      * <span style="background-color: transparent;">an HTTP-GET request on /{jobs} does not list by default archived jobs ; it is therefore possible using job list filter (see below)</span>
      * <span style="background-color: transparent;">no result is retained in this phase. But input files and error summary are kept.</span>
      * <span style="background-color: transparent;">the former execution phase (i.e. the phase in which the job was before being ARCHIVED) is kept as additional information in the _jobInfo_ XML node under the name _"oldPhase"_ _(this is hardcoded in the library, but it may be changed at any moment before the stable release if anyone notifies me on time)_ </span>

   * _Job list filters: PHASE, LAST and AFTER._ 
      * several PHASE filter may be specified ; if more than one is provided, all jobs in one of the given phase are returned (i.e. UNION of all PHASE filters).
      * using the PHASE filter with the value ARCHIVED is the only way to get the archived jobs
      * the LAST and AFTER filters work on the starting time (and not on the creation time as it could be intuitively expected)
      * only one AFTER filter is expected ; if several are provided, only the one with the most recent date is kept (which actually is the same as taking into account all AFTER filters)
      * only one LAST filter is expected ; if several are provided, only the one with the smallest value is kept (here again, it has actually the same behaviour as considering all LAST filters)
      * LAST is the only filter which performs a sorting of jobs ; sort by ascending starting time (from the first to the last started job ; from the oldest to the newest)
      * these 3 filters may be provided in the same time so that cumulating their effect
      * the character case (upper/lower/mixed case) is not important

   * _Blocking behaviour for /{jobs}/{job-id} with the parameter WAIT and PHASE._ 
      * WAIT is mandatory and is taken into account by the library only if an integer value is provided
      * special values for WAIT are: 0=no blocking, &lt;0=unlimited blocking time and &gt;0=waiting time in seconds
      * if several WAIT parameters are provided, only the one equivalent to the smallest waiting time is kept
      * PHASE is optional, but if provided it represents the phase in which the job MUST be when the blocking is asked ; if not in the specified phase, no blocking is performed
      * if several PHASE parameters are provided, only the last legal occurrence is taken into account
</div>

   * _Version attribute in the XML nodes &lt;jobs&gt; and &lt;job&gt; when they are the root document: version="1.1"_

   * _The new optional attributes "mime-type" and "size" for the XML nodes &lt;result&gt;_
*IMPORTANT NOTE:* the XML schema for the XML representation of all UWS objects MUST be updated when the document goes into the "Recommended" state.

<div id="_mcePaste"> *QUESTION:* Will the XML schema still be available at <a target="_blank" href="http://www.ivoa.net/xml/UWS/v1.0">http://www.ivoa.net/xml/UWS/v1.0</a>? Maybe should it be at <a target="_blank" href="http://www.ivoa.net/xml/UWS/v1.1">http://www.ivoa.net/xml/UWS/<strong>v1.1</strong></a>, no?</div>

-- IVOA.GregoryMantelet - 2015-10-30

Response to the above question:

According to the recently published XML schema versioning document [[http://ivoa.net/documents/Notes/XMLVers/20151029/NOTE-schemaVersioning-1.0-20151029.html#tth_sEc3][http://ivoa.net/documents/Notes/XMLVers/20151029/NOTE-schemaVersioning-1.0-20151029.html#tth_sEc3]], the document located at

http://www.ivoa.net/xml/UWS/v1.0

should remain as it is (UWS 1.0 stuff only), but a modified 'filename' URL will exist at:

http://www.ivoa.net/xml/UWS/UWS-v1.0.xsd

that has the "version=1.1" attribute within and the additions brought above by the 1.1 specification.

-- IVOA.BrianMajor - 2016-03-11

---++++ VO Paris Implementation (Mathieu Servillat)
---++++ CADC Implementation (Pat Dowler)

CADC has implemented all new features introduced UWS 1.1 for all their UWS-based services including TAP:

   * http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/tap/sync (auth-sync for userid/password)
   * http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/tap/async (auth-async for userid/password)

---++++ GAVO uws-client Implementation (Kristin Riebe, Adrian Partl)

The uws-client at <a target="_blank" href="https://github.com/aipescience/uws-client">https://github.com/aipescience/uws-client</a> is a Python tool to interact with UWS-services from the command line. We are implementing the UWS1.1 features; support for server-side PHASE-filtering (UWS standard section 2.2.2.1), including ARCHIVED-phase is already included as well as the WAIT keyword (with optional PHASE added) for the new blocking behaviour. The new "version" attribute is parsed, the client switches from the new server-side filtering to default client-side phase-filtering, if the version attribute is missing or not set to 1.1. Filtering using AFTER and LAST keywords was added in branch 21_job_list_filter.

Example usage (using gaia.aip.de as example UWS1.1 service):

   * uws --user uwstest --password gavo --host https://gaia.aip.de/uws/query list --archived
   * uws --user uwstest --password gavo --host https://gaia.aip.de/uws/query list --error --completed --last 10
   * uws --user uwstest --password gavo --host https://gaia.aip.de/uws/query list --after 2015-10-26T20:00+01:00
   * uws --user uwstest --password gavo --host https://gaia.aip.de/uws/query job show 1445885741809796726 --wait=10 --phase=PENDING

---++++ AIP Daiquiri - update to UWS 1.1 (Kristin Riebe)

I've updated our web application Daiquiri to include all (mandatory) UWS 1.1 extensions. It's not a full TAP server, it only supports UWS with a MySQL server in the background. The source code is available at <a target="_blank" href="https://github.com/aipescience/daiquiri/tree/uws_1_1">https://github.com/aipescience/daiquiri/tree/uws_1_1</a>. You can test it live at https://gaia.aip.de/uws/query, using the test user I just created with =username: uwstest, password: gavo=, or register for your own account. This allows you to test it e.g. with =httpie= like this:

   * http --auth uwstest:gavo "https://gaia.aip.de/uws/query?LAST=10"
   * http --auth uwstest:gavo "https://gaia.aip.de/uws/query?PHASE=ERROR&PHASE=PENDING"
   * http --auth uwstest:gavo "https://gaia.aip.de/uws/query?PHASE=ERROR&PHASE=PENDING&LAST=5"<br />This will remove all pending jobs from the list, since they do not have a startTime-value (LAST returns the most recently started jobs!)
   * http --auth uwstest:gavo "https://gaia.aip.de/uws/query?AFTER=2015-10-26T20:00"
   * http --auth uwstest:gavo --form --follow POST https://gaia.aip.de/uws/query query="SELECT * FROM GUMS10.Galaxies LIMIT 10"<br />This creates a new pending job. Use it's jobid in the next two steps.
   * http --auth uwstest:gavo "https://gaia.aip.de/uws/query/{jobid}?WAIT=30&PHASE=PENDING"
   * http --auth uwstest:gavo --form --follow POST https://gaia.aip.de/uws/query/{jobid}/phase PHASE=RUN
Notes on implementation: I like the new filter mechanisms and think they are really useful. AFTER and LAST were a bit unclear because they sort by startTime; PENDING and QUEUED jobs and those aborted at these phases do not have a startTime value. Now they are just ignored. I'd like to have a sort by 'creationTime' in the future for these cases. The repeated PHASES keyword caused trouble with standard PHP query parsing (it usually expects PHASE[]=...&PHASE[]=... if values shall be appended), but I solved this by parsing the request parameters manually. The service only returns 1000 jobs by default, but does not do a LAST-redirect since it would then lose all PENDING and QUEUED jobs in the job list. See grid mailing list for more discussions on AFTER/LAST.

---++++ TOPCAT/STILTS

The asynchronous TAP clients in topcat and stilts ([[ftp://andromeda.star.bris.ac.uk/pub/star/topcat/pre/topcat-full.jar][prerelease available]]) now use the blocking behaviour ( =?WAIT=-1&PHASE=...=) rather than repeated polls, for TAP services which identify themselves as UWS1.1 using the =version= attribute in the =&lt;job&gt;= document. This has been tested against Gregory Mantelet's TAP service implementation, and seems to be working fine. -- IVOA.MarkTaylor - 2015-12-07

---+++ Implementations Validators

Validator's for UWS 1.1:

   * <span style="background-color: transparent;">GAVO [[https://github.com/kristinriebe/uws-validator][uws-validator]]: It's rather a definition of tests for checking the new functionality of UWS 1.1, i.e. mainly job list filtering and blocking behaviour. It is using _behave_ (Python pacakge) and a definition of features and steps for testing the behaviour of UWS services. Some tests may still fail if I defined them too strict. Especially blocking behaviour may not behave as expected, my tests would fail but the service would still be valid. Tested with AIP's Daiquiri service (e.g. gaia.aip.de) and Gregory's TAP service at mintaka. Here are configuration files for these services: [[%ATTACHURL%/userconfig-gaia-aip.json][userconfig-gaia-aip.json]]</span><span style="background-color: transparent;"> (AIP Daiquiri service), </span> [[%ATTACHURL%/userconfig-gaia-mintaka.json][userconfig-gaia-mintaka.json]]<span style="background-color: transparent;"> (CDS/GAVO TAP service).<br />They can be used like this (needs additional installation of _behave_ first): </span> 
      * <span style="background-color: transparent;">For UWS 1.0 services only: <br /><span class="WYSIWYG_TT">behave -D configfile="userconfig-gaia-mintaka.json" --no-skipped --tags=-uws1_1</span></span>
      * <span style="background-color: transparent;">For the new UWS 1.1 functionality, excluding slow tests (waiting a long time): <br /><span class="WYSIWYG_TT">behave -D configfile="userconfig-gaia-mintaka.json" --no-skipped --tags=-slow --tags=-neverending</span></span>
   * <span style="background-color: transparent;">Any questions and comments are welcome! (Kristin Riebe, GAVO)</span>
CADC (and others?) have UWS 1.0 validators that still pass:

   * CADC UWS 1.0 Validator: [[https://code.google.com/p/opencadc/source/browse/#git%2Fprojects%2FcadcTestUWS][OpenCADC cadcTestUWS]]

   * [[http://www.star.bris.ac.uk/~mbt/stilts/sun256/taplint.html][taplint]] TAP validator within [[http://www.starlink.ac.uk/stilts][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 [[https://github.com/Starlink/starjava/blob/master/ttools/src/main/uk/ac/starlink/ttools/taplint/JobStage.java][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. -- IVOA.MarkTaylor - 2015-07-03 ... OK, there is one now, action on me to update the validator -- IVOA.MarkTaylor - 2015-12-07 I'm removing this action on me <nop>:-), since UWS blocking is hard to validate, as it's defined to be backward-compatible and can always behave as if it was non-blocking -- IVOA.MarkTaylor - 2016-02-17
<span style="background-color: transparent;">Please add your validator (even if 1.0) if applicable.</span>

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

---+++ TCG Review Period: 2015-09-09 - 2015-10-07

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

---+++ Comments from IVOA.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. <nop>ADQL, CEA [harrison05])" - is it anachronistic to refer to <nop>ADQL in this context since post-ADQL-2.0 there is no <nop>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" -&gt; "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=&lt;value&gt;" not just "WAIT"? 
      * <span style="background-color: transparent;"> done</span>
   * Sec 4.2: "<nop>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 <nop>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 [[http://mail.ivoa.net/pipermail/grid/2015-July/002768.html][schema evolution discussion]]) 
      * done in latest version of document and schema
-- IVOA.MarkTaylor - 2015-07-02 -- Replies IVOA.PaulHarrison - 2015-09-03

Thanks Paul - fixes all look good. -- IVOA.MarkTaylor - 2015-09-11

---+++ Comments from IVOA.WalterLandry

Regarding the new job query capability in Sec 2.2.2.1, it feels like<br />we are creating yet another query syntax with new keywords. To be<br />concrete, I would change the examples to
   * /{jobs}?QUERY=PHASE=EXECUTING
   * /{jobs}?QUERY=STARTTIME&gt;2014-09-10T10:01:02.000
   * /{jobs}?QUERY=TOP+100
"QUERY" and "TOP" come from TAP, "STARTTIME" comes from the UWS<br />SCHEMA. For now, the spec will only specify simple queries. So there<br />will be only one parameter in QUERY. But this allows future<br />expansion, so a more sophisticated service could allow full SQL
   * /{jobs}?QUERY=(PHASE=EXECUTING+OR+PHASE=COMPLETED+OR+PHASE=SUSPENDED)+AND+STARTTIME&gt;2014-09-10+ORDER+BY+ENDTIME

---++++ Reply by IVOA.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 <span style="background-color: transparent;">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</span>
   1 <span style="background-color: transparent;">There is a greater burden on the implementors to do the query parsing.</span>
It is for these reasons that I think that the "parameterized filter" style is more appropriate to a 1.1 update - if it turns out that there is demand for sophisticated querying then we can include a full ADQL query and associated schema in 2.0 - however in truth , I am still skeptical, as a UWS client should most of the time be keeping a local list of JOBIDs for the jobs that it submits and do all "queries" directly using the JOBID. The filtering mechanism in 1.1 is there just to make it easier for generic admin style web clients to not get overwhelmed with a long list of JOBs
---

---++ Comments from TCG members during the TCG Review Period: 2015-09-09 - 2015-10-07

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

---+++ TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler_ )

---+++ Applications Working Group ( _Pierre Fernique, Tom Donaldson_ )

---+++ Data Access Layer Working Group ( _François Bonnarel, Marco Molinaro_ )

---+++ Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel_ )

---+++ Grid & Web Services Working Group ( _Brian Major, Giuliano Taffoni_ )

I approve this document.

-- IVOA.BrianMajor - 2016-03-11

---+++ Registry Working Group ( _Markus Demleitner, Theresa Dower_ )

p.7, paragraph "ARCHIVED: At...": I believe "but the metadata associated with the job must be retained" was actually intended to be "but the metadata associated with the job *have been* retained" (or I don't get what this is intended to say).

   * agreed - changed in latest version
p.9, "Indicated in the job XML as a Nill element": I believe this should be "Nil" and that the double l in "nillable" is just morphological reduplication. (Also, Quote one paragraph down has "nil" with one l and in lower case; whatever you choose, it should be consistent)

   * have used xsi:nil in both places to be more precise about what is meant.
2.1.11 I thought that during RFC I had ranted somewhere to the effect that one single way to change parameters should be made "canoical" and the other deprecated. This would greatly help the implementation of UWS generic clients. I still believe this would have been a good thing, though I admit introducing such a change during TCG review might be inapproriate.

2.2.1 .../quote now returns an ISO timestamp. This differs from REC-1.0, where it returns an integer number of seconds. Since I'm not aware of any client making good use of quote and few servers actually returning something meaningful there, I'd not consider this serious, 2.0-justifying breaking the standard, but it should certainly be noted in the change log. Incidentally, I'd rather reference DALI here, since the ISO standard actually allows an almost infinite number of serialisations, so standards trolls might be tempted to play games with the current formulation.

   * actually the description of quote was the biggest inconsistency in REC1.0 - it was an error to descibe it in the [[http://www.ivoa.net/documents/UWS/20101010/REC-UWS-1.0-20101010.html#d1e834][table]] as being integer seconds as in the schema it was xs:dateTime. The [[http://www.ivoa.net/documents/UWS/20101010/REC-UWS-1.0-20101010.html#Quote][text description]] mentions comparing with the Destruction Time (implying that quote is a dateTime) but in a contadiction also talks of returning a negative value to indicate "don't know"(I will remove this too!). The decision was to clarify in 1.1 and follow the schema - The quote always was intended to be a "wall-clock" time for the server to try to indicate how busy it though it was, however the usual caveat applies that it is almost impossible for a server to provide a reasonable estimate.
On p. 11 it says "This URI should be given as the access URL in the UWS registration," but then no further comment is made on how such a registration might actually look like. To foster registration of UWS services, I would volunteer to contribute an informative appendix with a sample registry record for a UWS service.

Relatedly, I should have intervened a bit earlier because there's actually stuff a special UWS capability should note (support for ARCHIVED, perhaps limits on blocking times, plus there's limits on execution duration and retention time as in TAPRegExt...). Actually, I wonder if we shouldn't extend TAPRegExt for that purpose. This would mean adding a couple of (optional) elements and making language and outputFormat optional. If you agree that'd be a good idea unless bad things result, all that it would take was "UWS services SHOULD use TAPRegExt 1.1 capabilities as those become available" somewhere near the existing registration language.

   * <span style="background-color: transparent;">I am ideologically opposed to having the UWS capability derived from TAPRegExt as TAP derives partly from UWS and I do not like the circular relationships such a derivation would imply. In the original "grand vision" UWS can be used as a generalised pattern for any type of parameterised service beyond simply those that are part of DAL - as such the main piece of metadata for the service would be a reference to the PDL for the service - there was a start made to a specific UWSRegExt [[https://volute.g-vo.org/viewvc/volute/trunk/projects/registry/UWSRegExt/][quite a time ago]] </span>
Has anyone already written a StandardsRegExt record for this standard? If not and no one else steps forward, I volunteer to go ahead and draft one.

   * I think that you may be one of the few people who has the tools available to do this!
Like Mark, I'd like to see a bit more details on the implementations and where they actually run. I'd also feel much better if the blocking mode were demonstrated with an actual client^W^W^WTOPCAT.

-- IVOA.MarkusDemleitner - 2015-09-25 replies in bullets -- IVOA.PaulHarrison - 2015-10-15

***

Given that clients have now demonstrated blocking mode, I approve this document with the caveat that a standards RegExt for UWS needs to be created separately.

-- IVOA.TheresaDower - 2016-03-17
---+++ Semantics Working Group ( _Mireille Louys, Alberto Accomazzi_ )

1- The last line of the document reads:

<verbatim>$Revision: 1.27 $ $Date:
        2015-09-02 17:41:42 +0100 (Wed, 02 Sep 2015) $ $HeadURL:
        [[https://volute.g-vo.org/svn/trunk/][https://volute.g-vo.org/svn/trunk/]]projects/grid/uws/doc/UWS.html$</verbatim>

is it needed in the standard document ?

   * It is not a requirement, but I think that it is useful for a future author to know where the source file is managed - I think that you will see these sorts of references in future in most of the documents that are authored using the [[http://www.ivoa.net/documents/Notes/IVOATex/i][IVOATeX]] preparation system
2- Section 2.2.1.1.Determining the Protocol Version <br /> refers to the VOSI specification , but the VOSI label not appear <br /> on the architecture diagram .

   * I will update the diagram
-- IVOA.MireilleLouys - 2015-10-31 replies in bullets by IVOA.PaulHarrison
---+++ Education Interest Group ( _Massimo Ramella, Sudhanshu Barway_ )

---+++ Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick_ )

---+++ Data Curation & Preservation Interest Group ( _Françoise Genova_ )

---+++ Operations Interest Group ( _Tom !McGlynn, Mark Taylor_ )

As I noted above, this is basically a good document.

However, the Implementations/Validators part of the RFC page still looks to me rather underpopulated for a document in TCG review.

Three implementations are listed, but the implementation authors have not as requested filled in details, so it's not clear what the status of these implementations is, or where to go to see the code or running UWS 1.1 services. In particular, it's important that the implementations conform to the version determination arrangements described in sec 2.2.1.1, which have been revised during this RFC period.

There are no validators listed that test UWS 1.1-specific functionality, partly (in taplint's case at least) because there are no services to validate (if service providers want to blame validators for this chicken-and-egg problem - OK then let me know and I'll write the validation code first).

Since TAP is currently the most important(?) UWS client standard, before recommending approval I'd really like to see a TAP service whose async endpoint implements the new UWS features (I'm especially personally interested in the WAIT blocking in accordance with sections 2.2.1.1 and 2.2.1.2). Possibly there is one out there, but (despite my request in the Implementations Validators section) it's not clear from the information on this page where it can be found. If no TAP service can be persuaded to do that, I'd at least like to see a running UWS service implementing the new features.

-- IVOA.MarkTaylor - 2015-09-11

I have tested a working implementation of UWS1.1 blocking, against Gregory Mantelet's mintaka TAP service on 2015-12-07. Good! The list of implementations now looks much more healthy too. Ops is now happy to see this progress to REC. -- IVOA.MarkTaylor - 2016-02-17

---+++ Knowledge Discovery in Databases Interest Group ( _George Djorgovski_ )

---+++ Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo_ )

---+++ Standards and Processes Committee ( _Françoise Genova_)

<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
json	userconfig-gaia-aip.json	r1	manage	0.7 K	2016-02-24 - 08:40	KristinRiebe
json	userconfig-gaia-mintaka.json	r1	manage	0.7 K	2016-02-24 - 08:35	KristinRiebe
Topic revision: r28 - 2016-03-17 - TheresaDower
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema