<div dir="ltr"><div class="gmail_default" style="font-size:small">The home for these concepts depend on a couple of predictions we might make:<br><br></div><div class="gmail_default" style="font-size:small">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)<br><br></div><div class="gmail_default" style="font-size:small">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.<br><br></div><div class="gmail_default" style="font-size:small">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. <br><br></div><div class="gmail_default" style="font-size:small">my 2c,<br><br></div><div class="gmail_default" style="font-size:small">Pat<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 May 2018 at 17:21, Brian Major <span dir="ltr"><<a href="mailto:major.brian@gmail.com" target="_blank">major.brian@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi DAL, Registry and Grid,<div><br></div><div>Sorry for the wide distribution but this touches all three working groups.</div><div><br></div><div>An initial note for the UWS Registry Extension has been written and can be viewed here:<br><br> <a href="http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf" target="_blank">http://wiki.ivoa.net/<wbr>internal/IVOA/<wbr>IvoaGridAndWebServices/<wbr>UWSRegExt.pdf</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Brian</div></font></span><div><div class="h5"><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 22, 2018 at 4:58 PM Brian Major <<a href="mailto:major.brian@gmail.com" target="_blank">major.brian@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Grid, Registry,<div><br></div><div>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<br><br> uws:Sync or</div><div> uws:Async</div><div><br></div><div>instead directly in the standardID of the capability like</div><div><br></div><div> ivo://<a href="http://ivoa.net/std/tap#sync-1.1" target="_blank">ivoa.net/std/tap#sync-1.<wbr>1</a> and</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> ivo://<a href="http://ivoa.net/std/tap#async-1.1" target="_blank">ivoa.net/std/tap#async-<wbr>1.1</a></span><br></div><div><br></div><div>We have implemented this in our TAP (1.1) services using the XSD here:<br><br> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><a href="https://github.com/opencadc/reg/blob/master/cadc-registry/src/main/resources/UWSRegExt-v0.1.xsd" target="_blank">https://github.com/opencadc/<wbr>reg/blob/master/cadc-registry/<wbr>src/main/resources/UWSRegExt-<wbr>v0.1.xsd</a><br><br>And it is all working as expected, no issues.<br><br>Now I</span> 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.</div><div><br></div><div>Thanks,</div><div>Brian<br><div><br></div><div><br></div><div><br></div></div></div>
</blockquote></div></div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>