What are the requirements for managing context in specifications? #7
Replies: 1 comment
-
I’m trying to categorize the different use cases to maybe help us clarify some of the details and the scope of workflows that we can or should support in this spec. This comment talks about one of the OpenID Connect flows - #10 (comment) and as you can see it only works with multiple participants. I wonder if another dimension for this categorization can be single or multiple APIs, but it’s probably not as important and most of the spec should be the same in both cases. I’m mostly thinking about this from a code generation perspective - how can we use the spec to generate a client to execute the flow, and in this case the flows with multiple participants are probably the most complicated. Maybe from documentation and other perspectives it’s simpler. |
Beta Was this translation helpful? Give feedback.
-
The general thinking process around the formation of this SIG, is that we want to be able to define additional context which convey the goals, or key functions, of an API (possibly even a group of APIs).
Examples
In this discussion thread, we should aim to discuss valid use-cases and/or requirements for defining and managing the context representation. This can lead us to taking an initial pass as it's inclusion in the SIG proposal document.
Primary discussion points:
Beta Was this translation helpful? Give feedback.
All reactions