Home for the UWS Registry Extension?

[Mark Taylor]

Markus,

On Mon, 25 Jun 2018, Markus Demleitner wrote:

> [suggestion: let's continue this discussion on grid at ivoa.net; this is
> going to become ugly, and as it happens, schema versioning, which is
> giving a headache here, is grid territory as well]

OK I have restricted the recipients list accordingly.

> Oh bother.
> 
> If someone has a good idea how to clean this up, please speak up.
> Right now I'm suffering from a broken collarbone, which is my perfect
> excuse.

I haven't fully grasped what's going on here, I may chip in on that
if I manage to do so in the future.

But I have two comments to make about the following point:

> On Tue, Jun 12, 2018 at 11:21:39AM +0100, Mark Taylor wrote:
>
> >        version attribute.  Clients have to look for version="1.1"
> >        in (a? the?) <interface> element within the target capability.
> >        So the TAP (or whatever) service itself is not versioned,
> >        its various interfaces are.  That also raises the question
> >        of having multiple interfaces with the same securityMethod
> >        and xsi:type, but different versions.
> 
> As long as we have not identified strong use cases to discover by
> minor version, my take would be: interfaces declare the highest
> version they implement.  That would cover the "I need some extra
> feature only available since version 1.2" use case, which currently
> is the only discovery use case I find somewhat credible.

First, we're not just talking about discovery in the registry here,
this also applies to enumerating interfaces in a service's capabilities 
endpoint, and one can imagine 'discovery' use cases in that context
that are a little bit more flexible.  I agree that it's hard to
think of a good reason why a client might want to make a registry
query to find a v1.1 interface as distinct from a v1.2 one.
But one can imagine that a service provider might want to
advertise in the /capabilities document both a 1.1 and a 1.2
version - e.g. because the implementation code has changed
significantly between the two (they have different bugs) and
they want to allow the (well-informed) user to choose between them.

Second, I don't think this applies only to minor versions.
If at some point in the coming decades we have a TAP 2.0
then there will be reasonable discovery use cases that wish to
distinguish between 1.* and 2.* versions.

If as you propose there is a rule that says for each
capability+securityMethod combination a maximum of interface element
may exist (with the highest available version) then it's clear
to me as a service consumer how to handle them, so I'm happy -
but it may not serve all the use cases of service providers.

Get well soon.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/