GWS II discussion topics

[Patrick Dowler]

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.

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.



--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 10 May 2023 at 09:22, Russ Allbery <eagle at eyrie.org> wrote:

> Dave Morris <dave.morris at metagrid.co.uk> writes:
>
> > The session will look at the changes suggested by the Rubin team based on
> > their experience implementing SODA.
>
> > See
> > https://sqr-063.lsst.io/
>
> > We invite everyone to join the discussion. In particular we would like to
> > hear from developers or maintainers of clients and services.
>
> Hi everyone,
>
> Thank you, Dave, for the talk introduction! However, I think there may be
> some confusion about the intent of this talk that I can hopefully clear
> up. (I'm jumping in here because typing long email messages is difficult
> for Frossie at the moment.)
>
> While I did summarize in SQR-063 some elements of the SODA standard that I
> found surprising, the purpose of Frossie's talk tomorrow is not to propose
> specific changes to the standard based on that document. That level of
> detail work is probably better-suited to a working group discussion and
> drafts.
>
> The talk, instead, is intended to prompt and motivate a higher-level
> discussion about how we can evolve IVOA standards over time. SQR-063
> provides some examples as part of that motivation, but I'm sure other
> developers will have other examples of places where they would ideally
> like to make larger changes to the standards. I think the specifics are
> interesting primarily to frame the broader question of how the standards
> should evolve. Should standard changes be highly conservative to ensure
> that existing software does not need to change? Should the standard try to
> embrace changes in common practices and development frameworks when those
> changes may require incompatible protocol changes? How should we navigate
> the trade-offs between these approaches?
>
> In short, what do we want the IVOA standards to look like in five years,
> ten years, or twenty years in terms of their alignment with common web
> frameworks and newly-emerging development ecosystems? That's the question
> we want to ask.
>
> I think if we get into the weeds of discussing the specific examples in
> SQR-063 in detail, that won't be the best use of precious meeting time. If
> we agree on the ways in which IVOA standards should evolve with time, we
> can hash out the details with specific wording afterwards. If we try to
> discuss the specifics before we agree on direction and general principles,
> we're likely to be talking at cross-purposes and will not make much
> progress.
>
> --
> Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20230510/eba60c47/attachment.htm>