Ed-Fi RFC 5 - Change Log for v2.1a

Owned by Ian Christopher
Last updated: Apr 06, 2017 by Eric Jansson (inactive account)

Overview

This RFC for Data Standard v2.1a proposes a number of changes to the current standard that are intended to support – and designed in response to – field work using an earlier version of Ed-Fi data standards, primarily the Ed-Fi Data Standard v2.0.

To provide an easy entry point for community members into the RFC, we summarize below many of the significant and/or global changes proposed in this RFC. The full details of the changes can be found following the summary, recorded as individual tickets in the Ed-Fi Tracker. The individual tickets link to pull requests (on the Ed-Fi Alliance's GitHub repository) that show changes in individual code artifacts. 

Update of March 10, 2017

Please note that UML diagrams (in Visio) showing the changes from UDM 2.0 to 2.1a and a change log (in Excel format) are now available.

 

Significant Changes

Please be aware that the list of "significant changes" below is intended only as a starting point and helpful guide for reviewers and active users of the Ed-Fi Data Standard. Smaller proposed changes not covered may be of greater significance in some data exchange scenarios. Reviewers with existing implementations are encouraged to consult the list of individual changes following the summary.

Expansion of and changes to calendar model

The v2.0 model does not allow for representation of cases where students in a school would have individual, grade-level-based, program-based, or other calendars not shared by the whole school. Several field implementations have been working around these limitations. The proposed model introduces a Calendar entity to address this limitation, and an association from the StudentSchoolAssociation to allow for flexible association with individual students. It also simplifies the model by eliminating the CalendarDate abstraction, which did not appear to have much value in field work.

Addressing volatile keys

A number of developers of client code against the Ed-Fi APIs noted some entity keys in v2.0 that are volatile and subject to change, leading to difficult-to-write code and inefficient and error-prone integrations. A number of steps are proposed to reduce these issues, particularly in core entities of the model. The change in the Section key to rely in part on a source system surrogate key is likely the most significant change for existing implementations in this category.

Capturing Staff contact info

Multiple field implementations have extended the v2.0 model to capture additional contact information. From those needs, the proposed model adds support for capture of public contact info. These additions are intended to begin to distinguish management of externally-focused contact information (the proposed changes) from the management of internally focused contact information (current contact information associated with Student, Staff and Parent entities).

Fixing BellSchedule

BellSchedule has a serious bug in the v2.0 model requiring a fix. In addition, the model proposes a change to add flexibility to support class sections that have block schedules or other more complex scheduling requirements.

Expanding CourseTranscript model to allow for capture of external transcript info

In field work, the community has seen problems including transcript information from external school districts in the v2.0 model, due to the strong referential integrity requirements of the Ed-Fi model. For example, frequently a student transfers to a new LEA with only a paper transcript, and items on that transcript are not possible to assign to Courses or EducationOrganizations, as the data available to populate those entities may only be drawn from the lone paper transcript. The proposed model attempts to address such cases where academic work has a very "shallow" history, while retaining the ability of the model to capture "deep" history with high referential integrity, if needed by a particular field implementations.

Expansion to support credential capture

The proposed model expands and refines support for capture of education, teaching, and similar license credentials for staff, following norms established by field work in this area.

Clarifying and generalizing the core ID system for EducationOrganizations

The v2.0 system for identifying education organizations is not well-designed to support LEA use cases, and also includes some legacy fields that introduce confusion. A clarifying change is proposed.

Removing entities that cause excessive complexity with unproven value in field work

A few entities and attributes – most notably AcademicWeek and AssessmentFamily – are not adding clear value in field implementation work. Given that they also introduce ambiguity, their removal is proposed.

Individual Changes

key summary created reporter
Refresh