<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On duplicating the VOSI-capabilities deployment: sure you can do that but it makes the service deployment more complicated and means service providers have to write more tests to verify their service is working correctly. And when they register the service in an IVOA registry, which accessURL do they put? Obviously any would do since they are redundant, but someone has to document that and people have to understand that. It's smelly and it is not in the spirit of the DALI sibling rule which is that service endpoints are flat and not heirarchical.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On describing VOSI endpoints in the VOSI-capabilities doc: for services in general you need to do it because VOSI-availability is optional and has an arbitrary accessURL, VOSI-tables is optional (and there are use cases for both anon and auth). I agree that the VOSI-capabilities capability in the document is redundant (you know the url because you git the document) but that capability *does* have to be in the IVOA registry so we always just include it in the doc for completeness (heh - tap_schema describes itself, gcc in written in C, so why not here :-)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I will think about and respond to the main point. separately.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Pat</div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 12 Sep 2018 at 09:17, Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk">paul.harrison@manchester.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On 2018-09 -12, at 13:35, Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>> wrote:</div><br class="m_6945858031850145266Apple-interchange-newline"><div><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">Then there's no need to register all those sync and async</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">endpoints explicitly and no need for UWSRegExt.</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">The rest of the capabilities document could look substantially</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">the same as the current example, but with the additional rule</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">(analogous to the constraints already in TAP 1.0) that the other</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">declared auth-specific endpoints (tables and examples as well</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">as capabilities) MUST be located in the standard positions</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">relative to the corresponding auth-specific TAP base URL.</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">Then the 'child rule', as well as the sibling rule, works.</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">I think this is more or less what Paul was saying.</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote><div><br></div>Yes - this is what I am saying (and at first I did not realise that you had said it before me in the RFC) - it seems much easier to me, and more in keeping with the “spirit” of the original registry data model anyway.</div><div><br></div><div><blockquote type="cite"><div><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">To summarise: duplicating the capabilities document at auth-specific</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">endpoints means you don't need to break the sibling rule, and</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">hierarchical endpoint naming can be preserved, which I contend</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">(and Paul has also argued) is a Good Thing.</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote><div><br></div>I still think that it is better to do this way not only from the point of view that it keeps things simple, but also that it allows for the possibility that the /tableMetadata endpoint content should be different for the authenticated service anyway.<br><br><blockquote type="cite"><div><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">Am I missing something?</span><br style="font-family:Monaco;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></blockquote><div><br></div><div>An argument that might be used is that for the original SimpleXX v1.0 services there is an established use of the 'sibling rule' to find the capabilities endpoint (though there was no technical reason why a “child rule” could not have been adopted instead)</div></div><div><br></div><div>As far as I can see if you are handed a URL as a client and you have no idea what it is pointing to then you can try both the child and the sibling rules to find the capabilities endpoint to find out what service it is. In reality you will most often know what service the URL represents and your client can do the right thing (child for TAP 1.0, sibling for SIA 1.0 - though of course if you know what the service is then you don’t need to find the capabilities endpoint!) - it should be noted that this is the *current* state of affairs anyway, TAP 1.1 is trying to introduce a new more complicated regime where you have to always read the capabilities endpoint to understand what to do, and blurs the distinction about what *the* URL of a service is that I can cut and paste into an email/twitter message etc. The only sensible answer then is that the capabilities endpoint is *the* URL, but then there is an asymmetry with searching a registry for a service where it is wasteful finding the URL of the capabilities endpoint of a service rather than directly the service endpoint….<br></div><div><br></div><div>I actually question whether there is any value in putting the VOSI endpoints themselves in the capabilities endpoint content and registering them - it seems superfluous (apart from /availability, which could be a redirect anyway by modern DALI conventions) as they are supposed to be fixed anyway. </div><div><br></div><div><br></div><div>Paul.</div><div><br></div>
<br></div></blockquote></div>