<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On the whole topic of base URL vs usable endpoints:<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have been convinced for a long time that the whole approach we took in TAP-1.0 (8+ years ago) was wrong. We did specify that TAP has both sync and async query execution but we tried to pretend that it was one thing instead of two things. VOSpace has several different endpoints that behave differently and they are separate capabilities. If sync and async were just treated as separate capabilities from the start we would not have this problem and we don't have this problem with any other services. <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div style="font-size:small;display:inline" class="gmail_default"></div>On Wed, 12 Sep 2018 at 09:17, Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk" target="_blank">paul.harrison@manchester.ac.uk</a>> wrote:</div><div class="gmail_default" style="font-size:small">> <div style="font-size:small;display:inline" class="gmail_default"></div>and blurs the distinction about what *the* URL of a service is <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In my mind this idea is wrong and has always been wrong -- there is no *the* URL of a (TAP) service that is directly usable (eg that you can POST to) -- but we (DAL-WG and TAP-1.0 authors) had to make compromises to get TAP-1.0 to REC. We got the cardinality of service-capability-interface-accessURL wrong. It is more complicated than that because you have to just know to append one more special strings to the path to create usable URLs. That makes TAP special, which is sad when VOSI-capabilities is perfectly capable of describing endpoints so you don't need bespoke solutions and knowledge and we have proven that one can write and use a generic capabilities client to work out all the details. <br></div><div style="font-size:small" class="gmail_default"></div><div style="font-size:small" class="gmail_default">I am not arguing that it is impossible to comply with VOSI and DALI and keep a facade of "the URL" in TAP-1.1, but all the things needed to do that and avoid fixing the mistakes of TAP-1.0 make TAP more special and bespoke and less like the standard patterns in other services and the spirit of upstream standards. That means more text, more unforeseen consequences of that text, and less flexibility to use other standards to the fullest. It also means more code specific to TAP. <br></div><div style="font-size:small" class="gmail_default"><br></div><div class="gmail_default" style="font-size:small">If you still disagree with my claim that there is no "the URL to a TAP service" and there doesn't need to be one, then stop reading now because the rest is about how to fix things.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">When you realise you made a mistake, the first thing to do is "stop doing it". Ok, we also need some backwards compatible support for users/clients :-)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We made a mistake when we said the accessURL for TAP services was the base and not the usable endpoint(s). In a previous revision of WD-TAP-1.1 we did define versioned standardID values so one could have a separate capability for sync and async and this could live along side the old standardID for TAP-1.0 (which could have the base URL in accessURL). That worked exactly as well as the interface type mechanism (proven: we implemented both) and did not require any new stuff and did not break clients (e.g. topcat), but it would have a side effect of causing some recommended service discovery queries (RegTAP) return different results (not wrong just different cardinality). The interface type approach was an agreed way to avoid the service discovery side effects. <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Whether capability types (multiple standardID for TAP-1.1) or interface types (UWSRegExt note) is better is quite subtle. For the former:</div><div class="gmail_default" style="font-size:small">- it is a different type of service endpoint -- a different API -- in a service with multiple APIs</div><div class="gmail_default" style="font-size:small">- you can still use the TAP-1.0 standardID to tell old clients about the base URL and let them do magic</div><div class="gmail_default" style="font-size:small">- you can have different TAPRegExt metadata (eg limits) for sync and async</div><div class="gmail_default" style="font-size:small">- con: you have to duplicate common TAPRegExt metadata<br></div><div class="gmail_default" style="font-size:small">- generating a usable URL from registry lookup down involves a convenience method like: getEndpoint(resourceID, standardID, securityMethod)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For the latter:</div><div class="gmail_default" style="font-size:small">- the difference between sync and async is in the behaviour of the REST API and not in the kind of job; tagging interfaces directly matches that "different interface to a query job"<br></div><div class="gmail_default" style="font-size:small">- con: introduces new interface type tags (but RegTAP recommended queries ignore them because they use say ParamHTTP)</div><div class="gmail_default" style="font-size:small">- you can still use the TAP-1.0 interface type to tell old clients about the base URL and let them do magic</div><div class="gmail_default" style="font-size:small"><div class="gmail_default" style="font-size:small">- generating a usable
URL from registry lookup down involves a convenience method like:
getEndpoint(resourceID, standardID, securityMethod, interfaceType)</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Both of these approaches work, but personally, I liked multiple standardIDs more than multiple interfaceTypes. Some people didn't (RegTAP compat) so we discussed and compromised.<br></div><div class="gmail_default" style="font-size:small">Why do I prefer multiple standardIDs? It matches the spirit of "capability" in upstream standards. It lets you make sync or async (or both) optional and you have a way to describe which are provided. This exact approach thing is in REC-SODA-1.0 (sync and async).<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Aside: There is some debate
still about how much of the capabilities content should go into the
registry vs only in the served document. Suffice to say: some goes in
the registry - and clients that want to do special stuff will have to
check the document if they want to know all the possible options.
TAP-1.1 is not creating this scenario - it already exists because anyone
can put more content in the doc than the registry entry for any service
-- by design!<br><div class="gmail_default" style="font-size:small"><br></div></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><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr"><div style="font-size:small;display:inline" class="gmail_default"></div>On Wed, 12 Sep 2018 at 09:17, Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk" target="_blank">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_-6638328103852803180m_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, <div style="font-size:small;display:inline" class="gmail_default"></div>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>
</blockquote></div></div>