Page Comparison

...

• Discussion on material for review
  • Validation API
    • WI comments
    • Infinite Campus analysis
  • Open source rules engine
    • Edwire feedback
• Next steps

Documents

• Meeting deck: Rules_engine_and_Validation_API_SIG - Meeting 2.pptx
• L2 analysis from Infinite Campus

Participants

Audrey Shay , Wisconsin DPI

@bri

Meeting Notes

Discussion related to Ed-Fi Validation Results API specification 

• Discussed a comment in the document from Audrey Shay highlighting the fact that the current WI validation engine retains the same ID for for a validation result when data that was in error remains in error. Requiring a new ID each time would break some their existing functionality. After discussion Jon Hickam (Unlicensed)indicated that we would probably update the design to account for this.
• Audrey indicated that the WI team had also noted that there is no rule entity in the current design - which is needed to provide information about the validation rule that the result refers to. There was discussion and general agreement that this should be added to the design. 
• There was discussion of how you would determine which source system was the cause of a validation error/info message. Discussion clarified that this is not in scope for the design, nor is feasible, as a L2 validation message may be the result of an interaction between multiple source systems over data that is written to the ODS. Therefore, source systems that query the Validation API for results would need account for this and direct the message appropriately. 
• There was discussion related to the fact that multiple resources may be involved in a validation rule, so should the representation be 1:many. (Jon Hickam (Unlicensed)- can you clarify where we landed on this?)

Discussion related to use cases and issues surfaced by Infinite Campus 

There was good discussion around some of the potential issues identified in this document. Some of the main points that resulted from the discussion are summarized below:

• The information returned from the Validation API is intended to provide enough data and context to enable consuming systems to link validation messages back to source data and SME(s) for that source data. This is not the same as expecting a source system to programatically interpret and fix a L2 validation.
• With respect to the risk of violating HIPPA/FERPA or other privacy concerns, the intent is to use the existing Authorization mechanism in the ODS/API, which would address this concern
• TODO: There was a robust discussion (initiated by Doug Quinton) regarding potential refinements to the design, to make the API less "dumb" and less likely to overwhelm consumers with thousands of messages. Jon Hickam (Unlicensed) can you and/or Doug update the notes to reflect this ?

Discussion related to potential next steps

The proposed design of the Validation API is reaching a fairly mature state. There is still a lot to learn from actually trying it out in with real-world use cases and interactions between Ed-Fi implementations and SIS systems, and a proof-of-concept in a mature Ed-Fi implementation (with rules engine engine in place and willing SIS vendors to work with) is a preferred next step. An alternative would be to add this to the Ed-Fi Core team backlog - where it would have to compete with a myriad of other feature requests. SIG participants indicated that they would check with their respective organizations to gauge willingness to take this forward through a field implementation.