<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I was nominally editor for the last VOSI (the one with updates to tables) and can do so again.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I&#39;m fine with a single PR with multiple changes, especially when some are corrections or general cleanup that would otherwise not get done.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">will review asap,</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" class="gmail_attr">On Fri, 18 Feb 2022 at 09:31, Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; 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">Dear DAL, Dear GWS,<br>
<br>
[I&#39;d suggest followups to GWS]<br>
<br>
Pat and I have moved the VOSI sources to github,<br>
&lt;<a href="https://github.com/ivoa-std/VOSI" rel="noreferrer" target="_blank">https://github.com/ivoa-std/VOSI</a>&gt;.  <br>
<br>
The reason I am in this is because of the decision passed at the last<br>
Interop to no longer require availability endpoints (background:<br>
&lt;<a href="https://ivoa.net/documents/caproles/" rel="noreferrer" target="_blank">https://ivoa.net/documents/caproles/</a>&gt;. In the interest of reducing<br>
the number of bells and whistles that VO implementors may feel<br>
obliged to implement, I&#39;m suggesting to remove (almost) the entire<br>
spec of Availability (see below) in VOSI PR 1<br>
&lt;<a href="https://github.com/ivoa-std/VOSI/pull/1" rel="noreferrer" target="_blank">https://github.com/ivoa-std/VOSI/pull/1</a>&gt;.  I&#39;d much appreciate<br>
comments on this; in particular, we might decide to just make it<br>
optional instead, although I&#39;d then ask about actual use cases for<br>
burdening an interoperability spec with it.<br>
<br>
Into the PR I&#39;m also sneaking in a few Todos I noticed while scanning<br>
the document for text to change.  I&#39;d say a separate PR for that<br>
would be overdone bureaucracy, but I&#39;ll make one if people are<br>
actually concerned by the two-topic PR.  Or, yikes, turn them into<br>
Github PRs, although I&#39;d much rather have them in the interoperable<br>
git history than in the proprietary github issues, to be frank.<br>
<br>
Which brings me to the next question: Who&#39;ll serve as editor for this<br>
round of VOSI?<br>
<br>
Since I really would like to somehow resolve the situation that we<br>
require availability endpoints for all of our services, but only 367<br>
of 24804 actually have one (and, even worse, nobody bothers and the<br>
VO just runs fine with almost everyone violating this requirement),<br>
I&#39;d volunteer for the availability change (even if it were to mutate<br>
into just making it optional) and the todos I&#39;ve put in.<br>
<br>
But then I think the standard would profit from a bit more polishing,<br>
in particular smoothing out a few more SOAPisms that still are in<br>
there, and that I&#39;m not volunteering for.  Plus, I&#39;d much rather not<br>
be editor here.  So... if anyone else could see themselves serving as<br>
editor, I&#39;ll be really grateful (and already promise buying this<br>
editor a $BEVERAGE when there&#39;ll be proper interops again).<br>
<br>
Thanks,<br>
<br>
            Markus<br>
</blockquote></div>