Home for the UWS Registry Extension?

[Paul Harrison]

Hi,

I as I have stuck my head above the parapet, I think that I should probably comment on this as well….

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 interface more closely than a capability, and perhaps the idea of a generic CEA-like service would have its own capability, if such 'free standing UWS' services were to exist (and I admit that the idea does not seem to have gained much popularity - despite the fact that moving the code to the data and running workflows in the cloud being very much in vogue). Another point related to a generic UWS is that the “sync” endpoint only works for services that have only one “result” - part of the whole mechanism of UWS was to allow for multiple results.

Secondly I have to say that “feel” that discovering services in the registry should be easier - the logic of service discovery seems to be getting ever more complex, and it is perhaps because in the past the registry schema made things too flexible, and usage 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.

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

In summary - I think that this is probably the right point technical fix for the problem as things stand, but probably with wider implications than are apparent from the document title.

Paul.

p.s. after some time “away”, I have a feeling that there is still a “Grand Unification” waiting to be discovered amongst the many VO standards, to be able to see the small and beautiful core 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1905 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180824/4ac9cef3/attachment.p7s>