Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Participants


Expand


First NameLast NameOrganization
MattHoffmanAeries Software
John (Brent)KrollAscender
OscarOrtegaEdupoint
JoshBergmanSkyward
BradEvensonSkyward
NateGandomiEd-Fi Alliance
EricJanssonEd-Fi Alliance
VinayaMayyaEd-Fi Alliance
JeffPutnamEd-Fi Alliance
MustafaYilmazEd-Fi Alliance

Support: Ann Su, Ed-Fi Alliance

Agenda

  • Follow-up on the program to improve SEA data model alignment. We looked into the issue further and the perceived misalignment of Ed-Fi’s finding and the experience of the SIS SIG participants. We will report out on what we learned and our next steps.
  • Discussion of information on API Error Handling (presented at last SIG – see https://

...

...

Note - We will hold off on the agenda item of “Approaches and best practice for ‘shared’ API resources” to the March meeting. Thank you for your patience on that item.

Materials

View file
nameAPI Error Handling - SIS SIG.pptx
height150

Notes

API Error Handling

Positive response to the proposal generally as a means of helping the ecosystem resolve issues. Some points of discussion:

Can there be unique codes added? These might be helpful for a vendor to intercept/recognize certain errors and either better explain them or log them as internal programming issues?

  • Not a natural place for this in the RFC 945, but could be added in additional details or title.
  • Lots of permutations on what can happen and what the code is makes us question the utility. The response was that maybe all errors do not need codes, but there could be some that are the best candidates.
    • Example would be a schema error: the SIS client should never send one of these, so that would be a programming error
    • Another example might be a descriptor dependency: the SIS could also ensure these are avoided 
  • Will research this further

Can there be machine readable codes in the validations array?

There was a suggestion to add the Resource ID to the proposed format as well.

SEA Data Alignment

Alliance research (using materials sent by the SIS vendors) showed that while some elements are arguably semantically aligned, SEA are introducing complex business logic to sort, filter or otherwise reconfigure the elements of the data from the "natural way" they exist in the SIS (arguably this is layering on more semantics)

Proposal was for the Alliance to meet 1:1 with SIS vendors to onboard the most troublesome of these, and include those in the research. SIS participants on the call agreed to participate in this.

Another key point raised was that prevention is a lot more effective and important than going back to reform older specifications. The Alliance showed the changes to the SEA Implementation Playbook (State Education Agencies - Implementation Playbook) that had been made following the MSP/vendor meeting at the Summit and invited SIG members to submit other ideas or feedback.

Topic for Future Meeting

Advising states on their collections processes, for example, staggering collections more effectively

Next Meeting: