Open TSC Meeting, Thursday 29 October 2020

[MikeRalphson]

NOTE: This meeting is on Thursday at 9am - 10am PT

Zoom Meeting link: https://zoom.us/j/975841675. Dial-in passcode: 763054

In order to give some more visibility into the topics we cover in the TSC 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 TSC meeting

Topic	Owner	Decision/NextStep
Reserved character issue #2218
Human vs Machine consumption of OpenAPI
OpenAPI Usage documentation to a production state?
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

[Relequestual]

JSON Schema:
Does anyone understand / care about this issue? json-schema-org/json-schema-spec#833
I personally do not.

[darrelmiller]

@Relequestual I almost managed to resist commenting but failed.

[ncaidin]

If there is time, can we see if we can come up with a plan to get the OpenAPI Usage documentation to a production state?

[darrelmiller]

Human vs Machine:

Jonathan :

• Managing complexity via layers
• Can overlays enable this?
• Layers:
  • Info, paths/params/requestBody
  • Responses
  • Schemas

[orubel]

Issues mentioned pertaining to 'roles' per enpoint are in #2380

As per synchronizing your openapi files/state, see this video as to why it is important for all pieces of architecture (even if it is just one server) : https://youtu.be/A_Hozpb9gLc

[orubel]

Haven't gotten response from @darrelmiller on his solution from the issue I brought up at meeting so am posting this here...

His solution for #2380 states to put everything in URL which would dictate how the backend needs to work; OpenApi does not dictate how the backend works so this solution is not acceptable. OpenApi (like RAML and API Blueprint) is a REPRESENTATION of the state as it exists at the central version of truth. So this solution does not meet goals and needs of community at large due to:

• forcing one type of encoding for variables (URL vs HEADERS)
• lack of data types for sending variables associated with ROLES (array/list, map, etc) as it is URL encoded
• excessive verbage in that it cannot concatenate data from the 'anonymous' role (should they want to)
• requires different backend mapping/functionality; assumes RESTFUL vs RPC
• solution doesn't work for PUT/POST

Thus this FAILS as a solution for issue brought up during meeting

[orubel]

Mr @darrelmiller just stated in ticket #2380 that I sent 'threatening emails' (his words). This needs to be removed please. I would kindly ask for an apology but removal I believe is about all I can expect at this point.