<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Folks,<div><br></div><div><div>
<meta charset="UTF-8"><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 14px; font-style: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><font face="Calibri-Bold"><b>This is the email outlining concerns that we discussed this afternoon. The email went to DAL.</b></font></div><div dir="auto" style="text-align: start; text-indent: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><font face="Calibri-Bold"><b>I’m forwarding it to p3t.</b></font></div><div dir="auto" style="text-align: start; text-indent: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><font face="Calibri-Bold"><b><br></b></font></div><div dir="auto" style="text-align: start; text-indent: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><font face="Calibri-Bold"><b>Thanks for the 1/2 hour mtg today … I’ll write up notes. </b></font></div><div dir="auto" style="text-align: start; text-indent: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><font face="Calibri-Bold"><b><br></b></font></div><div dir="auto" style="text-align: start; text-indent: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><font face="Calibri-Bold"><b>-janet</b></font></div><br class="Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Mark Taylor via dal <dal@ivoa.net><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;"><b>P3T</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">May 23, 2024 at 6:16:40 AM GMT+10<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">dal@ivoa.net<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);"><b>Reply-To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;">Mark Taylor <m.b.taylor@bristol.ac.uk><br></span></div><br><div><div>Dear colleagues,<br><br>having let the P3T session yesterday sink in I wanted to make a few<br>comments.<br><br>[TL;DR: I've got reservations, but I'm not going to throw rocks in the way]<br><br>This proposal will lead to some fragmentation of the VO ecosystem.<br> Up till now we have, with a few exceptions<br>(e.g. PLASTIC->SAMP, SIA1->SIA2), been extremely conservative<br>about breaking changes to the standards, e.g. Cone Search responses<br>are still required to include UCD1s to the exclusion of UCD1+s that<br>replaced UCD1 in around 2006. The result has been that to a pretty<br>large extent all the client and server software that has been written<br>to date continues to interoperate. For long-lived standards such<br>as TAP and SCS new clients work with old services and old clients<br>work with new services, though enhancements introduced in later<br>versions of standards obviously are not available in those cases.<br>As far as it goes, I'd say that is a pretty good thing.<br><br>The current proposal lobs a cannonball into that approach so that<br>there is no chance of client/server code written for existing<br>standards interoperating as it stands with code implementing<br>the new versions of those standards. Similarly, client/server<br>code written to target the new versions will not interoperate<br>with existing implementations. The scope is currently TAP and UWS<br>but it looks like the thin end of a sizeable wedge;<br>phase 3 will target other standards, and several comments made<br>during the presentations seemed to indicate that we can expect<br>another similar round of breaking changes when OpenAPI falls<br>out of fashion in a few years time, and so on.<br><br>The no-legacy-code-left-behind vs. move-fast-and-break-things<br>difference between approaches is reminiscent to me of a comparison<br>between development of the Java and Python platforms/languages;<br>v1.1 of the Java application TOPCAT from 2004 runs happily under<br>Java 21 from 2021, but running older python code on recent<br>python platforms is typically much more problematic.<br>Neither approach is absurd; each has its pros and cons.<br><br>Gregory's presentation yesterday acknowledges the issue but I would<br>say understates the impact a little bit. Even assuming that the<br>major clients are adapted to work with both old and new APIs,<br>the existing "Informal client" sector will be unable to talk<br>to new services, and existing services will be inaccessible<br>from any new OpenAPI-based clients; Joshua was keen to point<br>out that such new clients are now going to be easy to develop.<br><br>I can see why the proposed changes appeal to large, well funded service<br>providers. But there are downsides from the point of view of legacy<br>services; newly developed clients will not talk to them and the<br>hurdle to take advantage of incremental changes in the standards<br>becomes higher. This model for standards development may come<br>back to bite those projects which are currently well-resourced<br>if they transition to maintenance-only mode in the future.<br><br>So, I'm wary of this way forward and I think people should be aware<br>of the impacts we can expect. But, maybe the benefits outweigh<br>the costs. Judging from the institutional involvement in the P3T<br>and from most of the audience response at yesterday's session<br>it looks like the prevailing opinion is that this is the way<br>we should go, and that it is going to happen.<br><br>I wonder whether there is a middle way: rewrite the standards<br>in terms of OpenAPI but do what we can to make them describe<br>existing service behaviour, minimising breaking changes.<br>There are two things being proposed here, and they are separable<br>to a degree: firstly providing machine-readable (OpenAPI)<br>definitions of the services, and secondly transitioning those<br>services to behave in a more modern way.<br>Page 8 of Joshua's presentation<br>(https://www.google.com/url?q=https://wiki.ivoa.net/internal/IVOA/InterOpMay2024P3T/dal-openapi-tech-overview.pdf&source=gmail-imap&ust=1717013822000000&usg=AOvVaw09NP7wNt6mc6adFMtg4KXX)<br>mentions one thing that can't be done in OpenAPI: case-sensitivity<br>of parameters. The other protocol changes described there are<br>more about how people would do things given a blank sheet of paper<br>than simply enabling machine-readable interface definitions.<br>Use of x-www-form-urlencoded parameters is said to be vulnerable to<br>CSRF, but there was some discussion on zoom about whether this is<br>really the case, I haven't looked into the details.<br>Case sensitivity we could probably fudge if we wanted to<br>(make a breaking but low-impact change to standards requiring no<br>modification for most code that uses uppercase anyway).<br>If the issue is really just about OpenAPI compatibility and<br>machine-readable interface definitions then perhaps it could be<br>done with significantly less impact than what's being suggested.<br>If on the other hand the appetite is really to take the<br>opportunity to update lots of things without regard to backward<br>compability, that's a different matter. But we should be clear<br>about the goals.<br><br>Whatever we do decide to do, I want the VO to work as well as possible<br>for users, so I'd volunteer to prototype client code at an early<br>stage in topcat and stilts. I will mention another class of client<br>that will need to be modified to work in dual mode: validators.<br>The taplint validator that forms part of stilts is a complex<br>tool widely used by TAP service deployers to check that their<br>services are operating according to the specs (I'd be happy for<br>others to develop a TAP validator, but nobody has), and if it<br>doesn't work for OpenAPI-based services I predict service<br>compliance and quality will drop significantly.<br>It is true that off-the-shelf OpenAPI validators can be used to<br>do part of the job of service validation in the new picture,<br>but there's a lot that goes on in taplint that I don't think can be<br>covered simply on the basis of understanding the OpenAPI contract.<br><br>I think this is going to require a significant amount of development<br>effort from client authors like me, but how much will depend on the<br>details of the proposal, so I look forward to the development and<br>results of the proposed Phase 1.<br><br>Mark<br><br>--<br>Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>m.b.taylor@bristol.ac.uk https://www.google.com/url?q=https://www.star.bristol.ac.uk/mbt/&source=gmail-imap&ust=1717013822000000&usg=AOvVaw3CwIj5PBWYFMLbE-QzCqin<br></div></div></blockquote></div><br></div></body></html>