...
| View file | ||||
|---|---|---|---|---|
|
Notes
The main topic of the meting was to explore the concept of an ODS that supports multiple operational contexts. See the attached slides.
There was some concern over losing the concept of a "national" context for interoperability (reinforced by Types), but in general the design where mapping is possible to various sets made sense to the group and was seen as a positive direction. It delivers on multiple possible enumeration sets.
A large point of discussion was if the ODS and API should require mappings to Ed-Fi governed values. There were points made for and against this.
For:
- Reinforces the overall message of interoperability and standards to adopters of the ODS and API
- Allows for data out in interoperable ways, per the examples
Against:
- It's not always easy or even possible to do such mappings: some state code sets can't map well. Forcing this creates some of the same friction and confusion around Types.
- Could encourage Ed-Fi's enumeration set values to be a super set of everything, and that is neither useful or realistic
Other notes:
- Better documentation and UI toolkits could go a long way to resolving the problem of reinforcing national contexts. The documentation of the solution does not present this concept early enough (in general, this reflects a lack of clear guidance on the solution setup).
- Generating consistent sets of descriptors across states is a challenge, and it would be good for there to be some community coordination mechanism for this. Unclear what that would be. This could use better oversight - encouraging convergence. Possibly could use Mapping EDU.
- Flexibility to send in state codes is critical to the solution, and can't be lost.
- The question of how an API or API client should negotiate context was brought up. It was noted that this is not yet determined, but one simple solution proposed was to link the API Client to a context via the key/secret.