Meeting: October 22nd, 2024

[earth2marsh]

Weekly meetings happen on Tuesdays

Time: 5pm GMT / 9am Pacific
Zoom: [NB: this meeting info changed to the LFX system on Oct 22, 2024] https://zoom-lfx.platform.linuxfoundation.org/meeting/98869769538?password=d769f940-7da7-4de8-9fab-685a1cc8f33e

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.

[handrews]

From the Oct. 15 meeting, we tentatively decided to focus on the lower boxes in the area currently labeled "Parsing and Resolution". Open questions include:

• How much (if at all) should we define a "DOM" for the grey box at the bottom? Really the only thing to do here beyond parsing into typical JSON/YAML in-memory representations is that you might want to impose a type system on the Objects and fields, and there's already enough info in the OAS to do this
• While simple parent-child relationships will look much the same via the grey DOM box and the pink ADA box, anything that has to be processed through the yellow box in the middle will need to look different. How should we handle those, keeping in mind that while 3.x has (at least) 9 different ways of making internal connections, we really hope that Moonwalk is simpler.
• What metadata needs to be kept from the grey DOM level and exposed via the pink ADA level?
  • For example, if you $ref a schema by its $id, that $id value may be significant as a URI for a standardized type (e.g. GeoJSON, or the Open Geospatial Consortium's extensions of that specification)
  • In 3.2, we plan to add self or $self which would allow for similarly stable identification of other components
  • Moonwalk might want to handle component identification somewhat differently
• How much do we hide from the ADA?
  • For example, would an application at the ADA level ever care that some query parameters were defined at the Path Item, rather than Operation, level? Or are they just parameters, and the level at which they are defined is an implementation detail of the OAD?
  • In some cases, we can't entirely hide things: Servers can be defined at four different levels, and three of those allow multiple definitions- we can hide which level produced the set of possible servers, but we need to offer the full choice among the servers

I might update this with more before the meeting, but this is a start

[earth2marsh]

Video now available