Ed-Fi RFC 6 - Change Log for v2.1b

Owned by Eric Jansson (inactive account)
Last updated: May 22, 2017
3 min read

Overview

This RFC for Data Standard v2.1b 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 May 22, 2017

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

Significant Changes to 2.0 Model

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 also uses the Cohort entity to allow for Calendars to be associated with groups of students.

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.

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.

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

AssessmentFamily as a concept introduced ambiguity, and its removal is proposed.

Differences from Data Standard v2.1a RFC

  • The v2.1b model reverts many proposed changes around CourseTranscript and StudentAcademicRecord, restoring a model with more referential integrity. The ticket explains many of the details as to this direction, but overall there was concern about limited evidence of a problem, a lowering of data quality, and some evidence that mapping transfer credits to local values is a standard practice. See http://tracker.ed-fi.org/browse/DATASTD-797.
  • While lowering key volatility is a concern that is addressed in v2.1b, it drops the proposed change to the key of GradingPeriod. While this is seen as a good direction for the future (the ticket is on the backlog), the change would be quite disruptive. See http://tracker.ed-fi.org/browse/DATASTD-917.
  • Several proposed model changes to EducationOrganization identifiers and identifiers for subclasses of EducationOrganization were omitted from v2.1b in favor of minor definition changes. As with previous changes, the concern was continuity and disruption to the ecosystem, and the changes will be considered for the future. See http://tracker.ed-fi.org/browse/DATASTD-972.
  • AcademicWeek will be retained in the model, as some evidence of usage was discovered. See: http://tracker.ed-fi.org/browse/DATASTD-974.

Individual Changes

key summary created reporter
Refresh

Â