Open Community (TDC) Meeting, Thursday 10 April 2025

[github-actions]

Weekly meetings happen on Thursdays at 9am - 10am Pacific

This agenda gives visibility into discussion topics for the weekly Technical Developer Community (TDC) meetings. Sharing agenda items in advance allows people to plan to attend meetings where they have an interest in specific topics.

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.

Meetings take place over 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 invite you to feel comfortable to challenge any 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)	TDC
Reports from Special Interest Groups (5 mins)	SIG members
Any other business (add comments below to suggest topics)	TDC
Approved spec PRs	@OAI/tsc
Active Projects	@OAI/openapi-maintainers
New issues needing attention	@OAI/triage

/cc @OAI/tsc please suggest items for inclusion.

[handrews]

• Add $self for self-identifying documents #4389 ($self)
  • This PR is struggling with a tension between people wanting more things explained and cautioned against, and people thinking there is too much explanation and context (both positions are reasonable, at least to some significant degree)
  • My personal preference would be to have a far more minimal specification, but that's not what we currently have, and a decade of experience trying to explain base URIs has taught me that people don't understand these things and need hand-holding
  • I really, really, really want to exclude any change proposals not directly part of the addition of $self from this PR; I know server URLs could be explained better and have many caveats, but that is not new with this PR (this has nothing to do with the validity of the concerns around servers, or the quality of the suggestions, which are quite worthwhile)
  • It would be good to get the basics in with this PR and keep talking about what we want for more comprehensive improvements
• Sequential (Streaming) media types and link to registry #4518 (sequential / streaming media types)
  • The problem here is that what people (quite reasonably) want is to model the application-level usage, but the Media Type Object models media types
  • The sequential JSON application-level usage seems to be entirely done where all elements in the sequence are of a common structure (or at least are subsets of a common structure, e.g. text/event-stream defines the overall structure, but not all fields are required)
  • The JSON media types themselves do not specify that all entries need to conform to a common schema (beyond being valid JSON values)
  • Users of text/event-stream in fact use "sentinel events" with special strings in the data field, although these cannot easily be modeled with JSON Schema as it lacks a postfixItems (at least so far- the keyword was under consideration to be added a couple of years ago, not sure what the status is now)
  • I'm not inherently against the more use-case-aligned approach of just modeling the contents with a single schema, but I don't see a way to square it with the Media Type Object, which works with HTTP content (effectively a document of finite length, even if it is logically a chunk of an indefinite-length resource – the point of these media types is that at some point you stop reading/buffering and start processing, and then read more (although this may be done in parallel, of course, but there's still some processing granularity within the stream)
• First pass at a media types registry. #4517 (media type registry)
  • Has two approvals from non-maintainers, just needs a maintainer approval
  • There is some back-and-forth but it is pretty much all about things that belong elsewhere (mostly in the Learn site) and not in this PR