Repository navigation
Open Community (TDC) Meeting, Thursday 08 September 2022 #3019
Description
NOTE: This meeting is on Thursday at 9am - 10am PT
Zoom Meeting link: https://zoom.us/j/975841675. Dial-in passcode: 763054 - Code-of-Conduct
In order to give some more visibility into the topics we cover in the TDC meetings here is the planned agenda for the next meeting. Hopefully this will allow people to plan to attend meetings for topics that they have an interest in. And for folks who cannot attend they can comment on this issue prior to the meeting. Feel free to suggest other potential agenda topics.
Please submit comments below for topics or proposals that you wish to present in the TDC meeting
The agenda backlog is currently maintained in issue #2482
| Topic | Owner | Decision/NextStep |
|---|---|---|
| Reports from Special Interest Groups | TDC | |
| Clarification of describing file downloads #3024 | ||
| Should OAI TDC consider creating an API Design language? | ||
| AOB (see below) | TDC | |
| New issues / PRs labelled review | @OAI/triage | |
| New issues without response yet | @OAI/triage |
/cc @OAI/tsc Please suggest items for inclusion
Activity
spacether commentedon Sep 7, 2022
How about we discuss this proposal #3024?
darrelmiller commentedon Sep 8, 2022
@spacether Sure. Happy to include that on the agenda. I think there is just some clarification required. I believe your scenario can be addressed without any new keywords.
handrews commentedon Sep 8, 2022
@spacether here is the PR where
{"type": "string": "format": "binary"}was replaced with{}(the empty schema, in conjunction with request/response content types) and{"type": "string", "format": "byte"}was replaced with{"type": "string", "contentEncoding": "base64", "contentMediaType": "whatever/the-type-is"}.Note that in the 3.0.x spec, the text actually sometimes wrote
"format": "base64"when it meant"format": "byte", so when you see"format": "base64"in the removed text, it should have been"format": "byte".The end text around the Encoding Object is not as clear as I'd like, but as @darrelmiller noted, we probably want to get rid of the Encoding Object anyway. If we do a 3.1.1 or 3.2.0 I'll probably try to improve the wording around the Encoding Object, though.
PR #2200
darrelmiller commentedon Sep 8, 2022
Let's review the open issues and understand the volume of issues that are calling for better authoring experience and which are calling for more capabilities (aka more complexity).
If we are going to explore a distinct design language, how would we do that?