Meeting: September 24th, 2024

[earth2marsh]

Weekly meetings happen on Tuesdays

Time: 5pm GMT / 9am Pacific
Zoom: https://zoom.us/j/975841675, dial-in passcode: 763054

Accessibility & Etiquette

• Participants must abide by our Code-of-Conduct.
• Meetings are recorded for future reference, and for those who are not able to attend in-person.
• We invited challenges to language or behaviour that is harmful or not inclusive during this meeting.
• We look forward to your participation, but please consider these acts of etiquette:
  • Remain on mute when not speaking to prevent interruptions.
  • Blur your background to reduce visual distractions.
  • Use the Zoom meeting "Raise Hand" feature to notify the group when you wish to speak.

Blur My Background	Raise Hand

Agenda Structure

Topic	Owner	Decision/NextStep
Intros and governance meta-topics (5 mins)	SIG members	--
General discussion topics (list below)	SIG members	--
Wrap-up and seed the next agenda (5 mins)	SIG members	--

Whether attending or not, anyone can comment on this issue prior to the meeting to suggest topics or to add comments on planned topics or proposals.

[earth2marsh]

Today we discussed @handrews 's recent blog post and diagram iteration. The discussion primarily focused on understanding the different colors, which we tentatively called the various "concerns" (as in the separation of concerns).

Gray, yellow, and pink (at least pink below the parsing line in the diagram) fall into the space where we might consider within our overall mandate. It was proposed that it would be generally useful to provide a tool that could validate that the semantics of a description were preserved as a document was converted between different spec versions (i.e., upcast and then downcast). This means not "losing" information in such a transformation, implying that deprecated features would need to be represented (likely via extensions). [NB: while writing up notes, it struck me that validation of a well-formed document should likewise be within our mandate!]

Video is available.

[handrews]

@earth2marsh I'm curious as to what this means:

Gray, yellow, and pink (at least pink below the parsing line in the diagram) fall into the space where we might consider within our overall mandate.

While the "below the parsing line" area is the part that impacts all implementations (either as a foundation, or because they are implementing part of that area), all of the concerns are there because they are defined by the OAS.

Even boxes like code generation are things that we sort of give guidance on (everything about polymorphism, for example, has nothing to do with anything but code generation or instantiation).

So it's not clear to me why anything on this diagram would be considered entirely "outside" of our remit. We may or may not want to nail down every aspect of every box, but we already specify at least part of every single one, to my view.

[earth2marsh]

Sorry, I could have been more clear! I meant in terms of what reference-like tools we might offer. The concepts are otherwise completely in our field of play!

[handrews]

@earth2marsh Oh, cool – yeah, since we want to define the ADA (whatever we actually end up calling it), that's the surface where we can test complaince and offer our own implementation for comparison (although whether we want to do that or just provide a test suite probably depends on available resources). Some other pieces are things for which we could offer reference implementations, but before even thinking about that I'd think about if there are other places in this diagram where we want to define some sort of standardized interface. Like "this is what the hand-off between data encoding and HTTP message assembly looks like" (an example only, it's not clear to me whether we would want to do that).