<div dir="ltr"><div class="gmail_default" style="font-size:small">Thanks for this doc! I agree that we shouldn't get into the weeds of the items in the doc tomorrow. I think they do provide a lot of details/examples that will allow the session to be more high level and conceptual.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What I would like to do (as an author or editor of some/most of these) is to sit down with 2-3 other people and go through the doc methodically to review and classify things into something like bug vs design flaw vs outdated vs working as intended. I don't think we can fit that in this week in person, so probably online at some point soon. Once we triage, we can post the result and discuss the details to see if any have more to them and to figure out actions for the future.</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><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 Wed, 10 May 2023 at 09:22, Russ Allbery <<a href="mailto:eagle@eyrie.org">eagle@eyrie.org</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">Dave Morris <<a href="mailto:dave.morris@metagrid.co.uk" target="_blank">dave.morris@metagrid.co.uk</a>> writes:<br>
<br>
> The session will look at the changes suggested by the Rubin team based on<br>
> their experience implementing SODA.<br>
<br>
> See<br>
> <a href="https://sqr-063.lsst.io/" rel="noreferrer" target="_blank">https://sqr-063.lsst.io/</a><br>
<br>
> We invite everyone to join the discussion. In particular we would like to<br>
> hear from developers or maintainers of clients and services.<br>
<br>
Hi everyone,<br>
<br>
Thank you, Dave, for the talk introduction! However, I think there may be<br>
some confusion about the intent of this talk that I can hopefully clear<br>
up. (I'm jumping in here because typing long email messages is difficult<br>
for Frossie at the moment.)<br>
<br>
While I did summarize in SQR-063 some elements of the SODA standard that I<br>
found surprising, the purpose of Frossie's talk tomorrow is not to propose<br>
specific changes to the standard based on that document. That level of<br>
detail work is probably better-suited to a working group discussion and<br>
drafts.<br>
<br>
The talk, instead, is intended to prompt and motivate a higher-level<br>
discussion about how we can evolve IVOA standards over time. SQR-063<br>
provides some examples as part of that motivation, but I'm sure other<br>
developers will have other examples of places where they would ideally<br>
like to make larger changes to the standards. I think the specifics are<br>
interesting primarily to frame the broader question of how the standards<br>
should evolve. Should standard changes be highly conservative to ensure<br>
that existing software does not need to change? Should the standard try to<br>
embrace changes in common practices and development frameworks when those<br>
changes may require incompatible protocol changes? How should we navigate<br>
the trade-offs between these approaches?<br>
<br>
In short, what do we want the IVOA standards to look like in five years,<br>
ten years, or twenty years in terms of their alignment with common web<br>
frameworks and newly-emerging development ecosystems? That's the question<br>
we want to ask.<br>
<br>
I think if we get into the weeds of discussing the specific examples in<br>
SQR-063 in detail, that won't be the best use of precious meeting time. If<br>
we agree on the ways in which IVOA standards should evolve with time, we<br>
can hash out the details with specific wording afterwards. If we try to<br>
discuss the specifics before we agree on direction and general principles,<br>
we're likely to be talking at cross-purposes and will not make much<br>
progress.<br>
<br>
-- <br>
Russ Allbery (<a href="mailto:eagle@eyrie.org" target="_blank">eagle@eyrie.org</a>)             <<a href="https://www.eyrie.org/~eagle/" rel="noreferrer" target="_blank">https://www.eyrie.org/~eagle/</a>><br>
</blockquote></div>