Identifying version of UWS

[Markus Demleitner]

Dear Grid folks,

On Tue, Sep 01, 2015 at 02:12:56PM +0000, Paul Harrison wrote:
> should be used to find out the version. It was initially assumed
> that the details of this would be in a ???UWSRegExt??? type of
> document - however, this document has never been completed and as

I have to say that I'd highly prefer if the registry extensions could
live in the main documents (as a rule) in the future, and I'd be
happy to help out with those. 

> I think that it would be a good idea to put in this extra
> definition of the standardId into the UWS document just for
> clarity. I believe that it should be defined as

Agreed.  I think there should be an example for how the capability
should look like in the docs, just as in the datalink document.

> "ivo://ivoa.net/std/UWS??? following the pattern of other services.

Ahhhh... that's a pattern I'm trying to break with Identifiers 2.0
that's in RFC right now.  I'd really like to see versioning in there,
plus the option to have multiple kinds of capabilities.  Hence, the
standard id should be

ivo://ivoa.net/std/UWS#rest-1.1

(with a corresponding standardKey in the registry record).

> The original mechanism within VOSI capabilities and the VOResource
> schema would mean that the version of the UWS server as a whole
> would be on the <Interface> element within the VOSI <Capability>
> element returned. This of course applies trivially for a

Ye-es.  That would have been an alternative, or still is, if someone
wants to champion a revision of the standards identifier thing.  I
have to say that in the meantime, I'd much rather recommend ignoring
the metadata on interface, as that's very unreliable at least in
current registry records; it's hard enough to get people to properly
use xsi:type="vs:ParamHTTP"...

The way things are envisoned now, the capability would be

  
  <capability standardID="ivo://ivoa.net/std/UWS#rest-1.1">
    <interface role="std" xsi:type="vs:ParamHTTP">
      <accessURL use="base">(whatever)</accessURL>
      (this could be used to declare input parameters; I guess it
      even should, although that might distract from providing
      PDL...)
    </interface>
  </capability>


> ???pure??? UWS server - for other services such as TAP the
> situation is perhaps slightly more complex (maybe the main standard
> i.e. TAP should mandate the UWS version ), though I believe that
> there would be no harm returning a ivo://ivoa.net/std/UWS VOSI
> Capabilities record with the appropriate UWS version (and indeed a
> TAP server being UWS 1.1 compatible) - especially as we are talking
> about a minor version update here.

Here, I don't feel terribly strongly, but what weak feeling I have is
we're doing us a favour if TAP mandates a fixed UWS version, lest
clients become lost in a combinatorial explosion of differing UWS,
TAP, ADQL, VOSI,... versions.

Cheers,

        Markus