<div dir="ltr">Hi Mark,<div><br></div><div>Thanks for the review and comments.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 12, 2018 at 3:21 AM Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</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">Brian,<br>
<br>
some comments as requested on the content of the UWSRegExt draft:<br>
<br>
Sec 1.1:<br>
The first sentence mentions the TAP 1.1 specification,<br>
but the citation is to TAP 1.0 (2010).<br></blockquote><div><br></div><div>It now cites the 1.1 PR, thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Sec 2.2:<br>
"Clients can recognize the TAP service as version 1.1 by checking<br>
for a version attribute with the value "1.1" in the capability."<br>
<br>
This is either confused or confusing (or I am): as far as<br>
I can see the <capability> element does not have a<br>
version attribute. Clients have to look for version="1.1"<br>
in (a? the?) <interface> element within the target capability.<br>
So the TAP (or whatever) service itself is not versioned,<br>
its various interfaces are.</blockquote><div><br></div><div>Okay, I've corrected that and made it clear that the version attribute appears in the interface not the capability.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That also raises the question<br>
of having multiple interfaces with the same securityMethod<br>
and xsi:type, but different versions.<br></blockquote><div><br></div><div>When another TAP version comes in the future (say 1.2) I think that such a circumstance would be an acceptable way of distinguishing between 1.1 and 1.2, no?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Sec 3:<br>
"... how the various UWS endpoints (namely the synchronous and<br>
asynchronous job execution endpoints) are to be discovered..."<br>
<br>
To me the synchronous endpoint is not a UWS endpoint at all.<br>
I would just write something like "... how the synchronous<br>
and asynchronous endpoints are to be discovered ...".<br></blockquote><div><br></div><div>Okay, I agree, that sounds better. Done.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
"The surrounding capability element should be marked with the<br>
minor version of service specification, as per the recommendations<br>
in the XML schema versioning note ((?)))."<br>
<br>
This looks like the same issue as noted above:<br>
<capability> does not have a version attribute. <br>
Does it need to grow one? Or do you mean the standardID<br>
should have a value which includes the standard's version?<br></blockquote><div><br></div><div>This should also have said 'interface' instead of 'capability'. Thanks, fixed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Sec 3.1 example capability document:<br>
The stanza following the comment "# TAP 1.0 support" is a <capability><br>
element inside a <capability> element. I don't think that's legal -<br>
should those two <interface> elements be present here on their own?<br></blockquote><div><br></div><div>Hmm, I don't see that in the version I'm editing. Perhaps it was fixed by someone else?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The accessURL for the authenticated (tls-with-certificate)<br>
TAP 1.0 interface is the same as for the unauthenticated one,<br>
accessURL="<a href="http://example.com/tap" rel="noreferrer" target="_blank">http://example.com/tap</a>". I think it should be<br>
accessURL="<a href="https://example.com/tap" rel="noreferrer" target="_blank">https://example.com/tap</a>".<br></blockquote><div><br></div><div>Yes, thanks, fixed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The stanza following the comment "# TAP 1.1 support" contains<br>
several <interface> elements with identical namespace declaration<br>
attributes xmlns:uws="<a href="http://www.ivoa.net/xml/UWSRegExt/v1.0" rel="noreferrer" target="_blank">http://www.ivoa.net/xml/UWSRegExt/v1.0</a>".<br>
This XML would (IMHO) be more readable if the that namespace<br>
attribute were factored out to an outer element<br>
(e.g. the top-level <capability>).<br></blockquote><div><br></div><div>I agree about the readability but, since the new 'type' values are an extension of 'Interface' in the XSD, doesn't that break the rules? Anyone know?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Sec 3.2 XSD:<br>
This schema references VOResource-1.0 - since VOResource 1.1 is<br>
now REC, should it reference that? Given the XSD Versioning Note,<br>
I *think* the only change required is to the<br>
xs:import/@schemaLocation attribute that should read<br>
"<a href="http://www.ivoa.net/xml/VOResource/VOResource-v1.1.xsd" rel="noreferrer" target="_blank">http://www.ivoa.net/xml/VOResource/VOResource-v1.1.xsd</a>"<br>
rather than<br>
"<a href="http://www.ivoa.net/xml/VOResource/VOResource-v1.0.xsd" rel="noreferrer" target="_blank">http://www.ivoa.net/xml/VOResource/VOResource-v1.0.xsd</a>"<br>
<br></blockquote><div><br></div><div>Good point. Yes, I think you're right that the only change is to the schemaLocation (Though I don't think this is because of the XSD versioning note, but because the namespace only serves as a label for the schema location. I've made that change as you recommend because it seems like it is at least in the same spirit as the schema versioning note.). I will change our implementation and test to make sure.</div><div><br></div><div>I've uploaded this latest version to the GWS main page:<br><br> <a href="http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf">http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf</a><br></div><div><br></div><div>Cheers,</div><div>Brian</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I still have my doubts about whether this approach is a complete<br>
or optimal solution to the problem of TAP services with multiple<br>
security methods, but this may not be the best place to air<br>
those concerns.<br>
<br>
Mark<br>
<br>
<br>
On Wed, 30 May 2018, Brian Major wrote:<br>
<br>
> Hi DAL, Registry and Grid,<br>
> <br>
> Sorry for the wide distribution but this touches all three working groups.<br>
> <br>
> An initial note for the UWS Registry Extension has been written and can be<br>
> viewed here:<br>
> <br>
> <a href="http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf" rel="noreferrer" target="_blank">http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf</a><br>
> <br>
> It is very simple: the essence of the note is to allow registry interface<br>
> entries to 'tag' interfaces as being UWS synchronous or asynchronous<br>
> endpoints. This is to allow implementers of UWS services (TAP is the<br>
> working example) the freedom of having separate URLs for interfaces with<br>
> various security methods (supported authentication) and to have custom URLs<br>
> for sync and async endpoints.<br>
> <br>
> Comments are welcome. There is still uncertainty about how the information<br>
> in this note should be brought in as a document for reference by TAP 1.1,<br>
> so comments on that are welcome too.<br>
> <br>
> Brian<br>
> <br>
> <br>
> 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>
> <br>
> > Hi Grid, Registry,<br>
> ><br>
> > At the Santiago Interop we decided to identify the sync and async<br>
> > endpoints of a TAP 1.1 capability by setting the 'type' of the Interface<br>
> > element as one of either<br>
> ><br>
> > uws:Sync or<br>
> > uws:Async<br>
> ><br>
> > instead directly in the standardID of the capability like<br>
> ><br>
> > ivo://<a href="http://ivoa.net/std/tap#sync-1.1" rel="noreferrer" target="_blank">ivoa.net/std/tap#sync-1.1</a> and<br>
> > ivo://<a href="http://ivoa.net/std/tap#async-1.1" rel="noreferrer" target="_blank">ivoa.net/std/tap#async-1.1</a><br>
> ><br>
> > We have implemented this in our TAP (1.1) services using the XSD here:<br>
> ><br>
> ><br>
> > <a href="https://github.com/opencadc/reg/blob/master/cadc-registry/src/main/resources/UWSRegExt-v0.1.xsd" rel="noreferrer" target="_blank">https://github.com/opencadc/reg/blob/master/cadc-registry/src/main/resources/UWSRegExt-v0.1.xsd</a><br>
> ><br>
> > And it is all working as expected, no issues.<br>
> ><br>
> > Now I am wondering now where this XSD can be placed within the IVOA and<br>
> > how it can be documented to describe the intended use. This will need to<br>
> > go somewhere official ahead of TAP 1.1. Any suggestions are welcome.<br>
> ><br>
> > Thanks,<br>
> > Brian<br>
> ><br>
> ><br>
> ><br>
> ><br>
> <br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</blockquote></div></div></div>