Versions Compared

Key

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


Section


Column
width50%

Ed-Fi Request for Comment 5: ED-FI DATA STANDARD v2.1b
Product: Ed-Fi Data Standard v2.1
Affects: Ed-Fi Unifying Data Model, Ed-Fi ODS / API, Ed-Fi Standard Interchange Schema
Obsoletes: ED-FI RFC 5 - DATA STANDARD v2.1a
Obsoleted By: --Data Standard v2.1 (released version)
Status: Active Proposal for Release Inactive


Column

Ed-Fi Alliance
May 15, 2017


Synopsis


This Request for Comment (RFC) includes materials that describe a proposed revision to the Ed-Fi Data Standard. The material in this RFC is designated v2.1b to distinguish the artifacts from previous releases and subsequent RFC material. This draft material is intended to support review and comment, and should not be used in active implementation work.

The proposed v2.1b models are designed to be evolutionary in nature from the current v2.0 models, and are more conservative in approach from the Data Standard 2.1a proposed models, in that they seek to curtail as much as possible the number of code changes required to support an upgrade to exchanges defined via the 2.0 Data Standard.  Changes proposed under 2.1b are mostly additive and optional, or affect places in the model not widely operationalized.

However, in a few places "breaking" changes have been introduced. This has generally only been done when there was a serious issue confronting field implementations and/or there was sufficient evidence that not introducing such a change would lead to multiple workarounds or extensions to support similar needs. In such cases, it was judged that overall stability of the ecosystem is better preserved by making a few changes to align the community on common data models and approaches.

The resulting work is designed to deliver a stronger, more flexible, and improved core data model, but also be of a size and scope such that existing implementations can plan to adjust and upgrade systems without undue cost and complexity.

To align with data governance cycles for K–12 agencies for data use in the 2018-19 school year, the Ed-Fi Alliance, working with the community, plans to publish final specifications in June 2017. We encourage early feedback on the proposed changes to assist with a timely release.

Contents


This RFC includes the following material:

Page Tree
root@self

Feedback


Community feedback is critical to the RFC process, and the Alliance welcomes feedback from anyone.

Feedback does not need to be long or comprehensive. It is enough to cite a particular K–12 use case where the model would or would not be able to represent a common data exchange scenario. However, if readers have more lengthy written feedback, existing reports or alternative fully-articulated data models, please feel free to share those.

The primary mechanism for feedback is via the Ed-Fi Alliance general project in the Ed-Fi Tracker. Licensees can submit new RFC 6 feedback by clicking this link (login required). Licensees and the general public can view existing feedback here: http://tracker.ed-fi.org/projects/EDFI/ (login not required). When entering a feedback ticket, please reference the change or specific fix on which you are commenting, if applicable.

If you need an account for the Tracker, please go to http://www.ed-fi.org/access-request/ (note the Technical Community Guidelines if you are curious about what Ed-Fi Alliance services you can access).

Community discussion is also welcome via Ed-Fi Slack.

 

Detail


We encourage interested parties to consult the Ed-Fi RFC 6 - Change Log for v2.1b for a narrative of major changes and links to artifacts with details on individual work. 

Anchor
errata
errata
Errata


Errors discovered with the models that are intended to be addressed in the final version are listed below.

  • Per DATASTD-914, the association between Students and Calendars under Data Standard 2.1b is via Cohorts (Cohort.Calendar). The published 2.1b models failed to remove the association via a Calendar reference on StudentSchoolAssociation. This is a mistake: the 2.1a reference StudentSchoolAssociation.Calendar should have been removed.
  • Per DATASTD-914, the cardinaility of Session.Term was intended to be 1 (i.e. a required field), not 1..n (a required collection). This is a mistake; the same mistake also appeared in Data Standard 2.1a.

See Also


Links to additional information, draft documentation, and other non-normative content related to this RFC will be added below as they become available.