Identifying version of UWS

[Paul Harrison]

> On 2015-09 -01, at 17:25, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
>> 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).

I was being deliberately provocative, as I had seen that the more modern standards that the “fragment” form had been used to indicate the version - I was just pointing out that the VOResource schema does have a placeholder for such information, and for most of the standards up to DataLink there is a problem with this, as the *RegExt schema have defined the standardId explicitly - see below.

> 
>> 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>
> 

It is the design decision that the Interface was chosen to be abstract in VOResource that forced “*RegExt” schema that I regret now - However, the standardId (without the fragment) has been “burned into” several of the existing protocols in the *CapRestriction types (an example of using an XML schema “trick” - never a good idea), and not that easy to undo this, without updating all of the *RegExt schema - in many cases the RegExt schema do contain desired extra metadata, so your example above would not work for them as the Capability would need the xsi:type=“sia:SimpleImageAccess” for instance. This is not the case for UWS of course as it does not have a *RegExt schema - so the example above could work - although if I were doing the update to the *RegExt schema then I would also make VOResource Interface non-abstract so that a vs:ParamHTTP were not forced - as the declaration of the standardId should tell a client everything it needs to know about how to operate the interface  - vs:ParamHTTP was there to specify the arbitrary “optional” parameters that were allowed on some protocols, but is not sufficient to describe them fully enough to be useful. It might be useful to remove the version attribute from Interface too, so that that there is no possibility of a contradiction in the capability standardId fragment version and the version declared on the interface.

I am not against using the fragment identifier to do the versioning - it is just I think that we should clean up the existing schema to make this uniformly possible - This might be as simple as removing the *CapRestriction types, and hopefully could be done under the “minor change” rules that would not mean new namespaces.

Paul.