Versions Compared
compared with
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Agenda (proposed)
- Review of & feedback on Ed-Fi Alliance programs to reduce API fragmentation and burden
- Review state alignment work
- Review playbooks
- Use cases that underlay our specifications
- Feedback on Error Code and Error Handling proposed changes (from Meeting 1)
- Review of priority interventions for 2024 specifications
- Topic for future meeting/asynchronous review: Integration Architecture for Data Providers
Materials
- 2023 SEA Ed-Fi Overview and Implementation Playbook.pdf
- Program to improve alignment of state specifications
- Use case documentation: SIS API V4 Certification Use Cases
Notes
Error Code and Error Handling
- SIS systems shared that today they do not re-write Ed-Fi API error messages. When asked they would use a new "error code", the response was generally that this would be a lot of work, and the hope is to avoid that.
- They shared that their primary desire is for API error messages to be understandable by a LEA staff who uses the SIS, who is likely non-technical. The primary use cases they envision to just forward messages as is (what they do today)
- The SIS systems did also say they see the need for a technically detailed and accurate message, as a means of supporting developers. However, per the above points, such a message is not appropriate for a district SIS user, who it confuses.
- When asked if they see future utility in the error codes, most SIS systems said they would like that option and may use it as their work goes forward.
- Some suggestions:
- have 2 error messages: 1 for technical users/developers and 1 for district SIS users (also, SIS system participants pointed out that a new developer would also benefit from the "simpler" message)
- Include both a simple and a technical message with some kind of delimiter, but put the simple message first
- avoid ANY technical jargon in the simpler message (the example from the deck was why even say "uri" - just say "code value")
Alliance support for SEA alignment
Generally like the SEA Playbook direction - want to review the details more
Some narrow points of feedback:
- for SEA planning, 3-6 months planning is not enough - needs to be 6-12
- The planning stage needs to end (and only end) when a SEA Swagger/sandbox is released
- as a (new) best practice, states should solicit feedback from vendors on their data modeling / API specifications
- the misalignment can lies with the MSP or consultant a state is using; in particular, the guidance should be strongly to use Ed-Fi as it is defined, and not to "recreate" the current data model of the SEA via extensions and re-writes, as this adds huge overhead to vendors work across states
On the review of SEA data specifications
- Strong positive feedback - please continue this!