Home for the UWS Registry Extension?

[Patrick Dowler]

The  home for these concepts depend on a couple of predictions we might
make:

1. Is it useful for UWS to be extended to specify interface behaviour for
synchronous job execution? TAP, SODA, and VOSpace all have "jobs" that can
run  in either mode and s/w choses the endpoint with the behaviour it
wants... the minimal "specification" of UWS-sync would be a standard way
for a client executing a sync job to get the jobID and access it via a
joblist (eg in UWS-next)

2. Ae there common metadata about the UWS job endpoint that could be
conveyed by adding content to the UWSRegExt? e.g. will UWSRegExt go beyond
providing tagging interface in future? This one I am less sure about.
TAPRegExt already describes some of the UWS job control limits, for
example, but that reg-ext defines a new capability type (the type of
job)... I do have some UWS-defined features that are interface-specific  so
there are use cases.

I do think it is important for us, as a community, to find ways to do small
things and get them done in a short time, and then iterate more rapidly on
minor versions.

my 2c,

Pat

On 29 May 2018 at 17:21, Brian Major <major.brian at gmail.com> wrote:

> Hi DAL, Registry and Grid,
>
> Sorry for the wide distribution but this touches all three working groups.
>
> An initial note for the UWS Registry Extension has been written and can be
> viewed here:
>
>     http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/
> UWSRegExt.pdf
>
> It is very simple: the essence of the note is to allow registry interface
> entries to 'tag' interfaces as being UWS synchronous or asynchronous
> endpoints.  This is to allow implementers of UWS services (TAP is the
> working example) the freedom of having separate URLs for interfaces with
> various security methods (supported authentication) and to have custom URLs
> for sync and async endpoints.
>
> Comments are welcome.  There is still uncertainty about how the
> information in this note should be brought in as a document for reference
> by TAP 1.1, so comments on that are welcome too.
>
> Brian
>
>
> On Thu, Feb 22, 2018 at 4:58 PM Brian Major <major.brian at gmail.com> wrote:
>
>> Hi Grid, Registry,
>>
>> At the Santiago Interop we decided to identify the sync and async
>> endpoints of a TAP 1.1 capability by setting the 'type' of the Interface
>> element as one of either
>>
>>     uws:Sync or
>>     uws:Async
>>
>> instead directly in the standardID of the capability like
>>
>>     ivo://ivoa.net/std/tap#sync-1.1 and
>>     ivo://ivoa.net/std/tap#async-1.1
>>
>> We have implemented this in our TAP (1.1) services using the XSD here:
>>
>>     https://github.com/opencadc/reg/blob/master/cadc-registry/
>> src/main/resources/UWSRegExt-v0.1.xsd
>>
>> And it is all working as expected, no issues.
>>
>> Now I am wondering now where this XSD can be placed within the IVOA and
>> how it can be documented to describe the intended use.  This will need to
>> go somewhere official ahead of TAP 1.1.  Any suggestions are welcome.
>>
>> Thanks,
>> Brian
>>
>>
>>
>>


-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20180530/c5286df6/attachment.html>