uws 1.1: job list filtering

[kristinriebe]

UWS1.1. services allow to filter the job list by appending corresponding parameters, copied from the standard, section 2.2.1:

1. Filter by phase, e.g.
   {service-url}/{jobs}?PHASE=EXECUTING

2. {service-url}/{jobs}?AFTER=2014-09-10T10:01:02.000:
   The server should only list jobs with start times after the given [std:iso8601] time in UTC.

3. {service-url}/{jobs}?LAST=100
   The server should list only the given number of most recent jobs ordered by ascending start times.

Filters can be appended, which is to be treated as a union/logical AND.
Servers may respond with a 303 redirect to the jobs-url including a LAST-filter, if the job list is too long.

[adrpar]

is there a way to identify if a service speaks UWS1.1 before actually issuing a call? Is there something like HEAD in rest or a version endpoint?

[msdemlei]

There was a discussion on this that I only followed with less than half an eye, and I can't seem to find it on the grid-WG archives (http://mail.ivoa.net/pipermail/grid/), so I guess it must have been in Sesto. Given that, I guess it's fine asking on the list.

[kristinriebe]

Can we use VOSI for this? I got the impression that the /capabilities endpoint is designed to give information about the version, supported features etc.

[msdemlei]

We could, if UWS had a proper, versioned standard-id. Which, as far as I can tell, it hasn't so far. It would have to be defined in the UWS 1.1 document together with a recommendation for how the capabilities element should look like. Not a big deal, I guess, but someone would have to do it.

I'd ask on the gws mailing list first, either way.

[adrpar]

@kristinriebe can you raise this on the mailing list? I will do a try error strategy for the implementation, but proper versioning, even of the standard namespace would be nice (i.e. the existence of http://www.ivoa.net/xml/UWS/v1.1.

[kristinriebe]

I've asked the ivoa-grid list, these are the main results:

• In UWS 1.1, each xml response at /{jobs} and /{jobs}/(job-id) must have a version attribute in the top level element of the responses, i.e. it starts with <uws:job version="1.1" xsi:schemaLocation=...>. So if version="1.1" is there, you can assume UWS 1.1 is implemented, if the attribute is not there, then it's 1.0.
• VOSI is another possibility, but maybe the version attribute is already sufficient for our purposes, since we then do not need to assume that VOSI is implemented?
• namespace: the current draft still cites http://www.ivoa.net/xml/UWS/v1.0, but I believe it should be http://www.ivoa.net/xml/UWS/v1.1 once UWS 1.1 made it to recommendation. It's not yet there, though. We could put the current 1.1 schema at a local url, if you need it for schema validation or some such.

[adrpar]

Looks ok for me (partially). Still this requires a call to an UWS endpoint and the retrieval of XML first, to actually know what the client can do. This is a little a hen-egg-problem... but ok.

[kristinriebe]

Update for namespacing: It's actually not going to change, since the update to 1.1 is a minor revision and it is considered more harmful if namespaces change than it helps, so the namespace will stay as http://www.ivoa.net/xml/UWS/v1.0. This should always refer to the latest released version (older versions will be moved somewhere else). Detailed reasons are given in the not yet official note by Paul Harrison: https://code.google.com/p/volute/source/browse/trunk/projects/grid/notes/schema-versioning/schemaVersioning.tex#298.
EDIT: In order to not break anything, the "version" attribute is formally "optional" in the UWS 1.1 schema, but in the UWS 1.1 document it will be stated that it must be added nonetheless, so you can rely on this attribute if it's a 1.1 service, but cannot expect it from 1.0-services.

[kristinriebe]

One more comment: there are services that implemented UWS1.1 only partially and thus have the version attribute still set to 1.0. The problem is that the user may know what features are supported, but the uws-client won't use them, because it relies on the version attribute.
I guess we could add a command line option (or set it directly inside main.py?) to force to assume a UWS1.1-service, overwriting the given version-value? This would be valuable if developers want to use the uws-client for testing their services (as we may want to do when implementing UWS1.1 in Daiquiri).