Home for the UWS Registry Extension?

[Markus Demleitner]

Hi,

On Fri, Aug 24, 2018 at 04:04:05PM +0000, Paul Harrison wrote:
> My first area of initial unease is that the original conception of
> a "free-standing" UWS service (which should obviously be
> registered) was modelled on the old Astrogrid CEA service which was
> a facade for just about any sort of application that you want to
> put behind it. Having said that I think that UWS does describe an

Oh, this effort is, for now, not concerned with the actual
description of UWS services.  I deals with interfaces, and that it
talks about UWS is, from my view, rather ephemeral.

The effort started mainly because sync and async paths will be
decoupled in TAP 1.1, and that needs to be mapped in some way to
VOResource/the capabilities endpoint such that it doesn't interfere
to badly with existing practice.  This decoupling, in turn, is more
or less necessary to support, at the same time, common authentication
mechanisms (which require different endpoints on the same capability)
and VOSI (which requires that capabilities is a direct sibling of the
other access URLs in order to make it computable).

Yeah, it's not pretty, but it's one of these things.  See also
http://wiki.ivoa.net/internal/IVOA/InterOpOct2017GWS/tapdiscovery.pdf,
which gave a brief introduction into this.

> Secondly I have to say that "feel" that discovering services in
> the registry should be easier - the logic of service discovery

Yeah, so does everyone.  But really, the concept of "A service has a
couple of capabilities, each of which can have a few interfaces, each
of which has an access URL and possibly a couple of mirror URLs" is
about as simple as we'll ever get it.  Each level is in active use
not (just) for exotic fringe cases but for fairly fundamental
modelling of our resources.

So, while I'd love to be proven wrong, I expect a hypothetical
"Registry 2" project would arrive at something not terribly different
from what we have now, including using TAP for querying the thing.
Sure, you might add some simplified discovery protocols on the way,
but you can do that on top of the current registry, too (I think VO
Paris operates one of these).

Oh, one thing I'd change if I did it again: standardIDs would be
unversioned in my Registry 2.

> guidelines we not strict/clear enough. This extension does
> effectively lay out a "new" pattern for registering services,
> and as such probably has scope beyond just "UWS", so I am not
> sure about calling the document UWSRegExt - perhaps it should take
> the tone of "Registering Services for Discovery" and have the
> UWS registry extension as an example of the new practice.

Let's not bikeshed about the name of this thing.  I still hope to
absorb it into VODataService when it has matured, and even if it
doesn't go there, we can try to agree on the REC's name when we do
the WD.

> On a few of the technical points on namespaces
> * it does not matter that uws: is being used in this registry
> context - it is distinct from the uws: in UWS service replies - the
> instance documents do not have to use "uws:" anyway, they can
> use any prefix they want.

True.  For the benefit of onlookers: In a Registry context, prefix
mapping isn't nearly as free. Using a canonical prefix in VOResource
documents is -- at least -- strongly recommended, mainly because the
prefixes end up in attribute values (where standard XML processors
can't reach them), and these in turn become user-visible in non-XML
contexts (like RegTAP columns).

> * we should not require any particular style of local or global
> namespace declaration - as long as the document is valid -
> different libraries have different styles, and we do not want to
> stop people from using their favourite library.

Absolutely.  Let's not bikeshed on this, either, but rather make sure
that the presentation in the document is as compact and
non-intimidating as possible.

        -- Markus