TAG Meeting 2017-06-07

Materials

Vendor certification and topic of more flexible models

Local certification has "little teeth" - support for a centralized model by the Alliance is desirable
Getting the data to the ODS is the real problem, not the data domains themselves. Is it possible to certify on a transport spec?
Assessment vendors looking to pull the data from the ODS - consumption specs. Other examples of this provided.
Is certification by API profile an option?
Certification is more work for vendors - yet one more thing that needs to be done

Data Thrashing (see slides)

Authorization view - dates are not factored into the authorization query
Other states have the same problem - "last one wins" - when there is a dual-enrolled students (no examples of the WI case cited, where there is not dual enrollment per se
In the ODS API, it is possible to produce a custom authorization to solve this problem, but that is complex
Action: the direction seems to be to reverse the authorization to be more restrictive and offer an alternative configuration option for less restrictive. Captured as ODS-1215 - Getting issue details... STATUS

API Validation

No concerns raised re advocating the May TAG meeting conclusions as a best practice
Concerns re performance should also be noted
State has more strict rules, local rules are less stringent
Vendors doing deletes was a problem as well
Would be challenging to vendors to log these warnings; vendors already log API errors. Overall, these warnings are likely to be ignored.
Exposing warnings as a separate endpoint (e.g. /errors) seems like a better option, as that could allow for others to consume. When offered synchronously, error messages can only be consumed by the API client. A generic endpoint could serve as a key piece of infrastructure for any agency building downstream "Level 2" validations