Updates to the Ed-Fi Data Standard for v2.0.1

The Ed-Fi Data Standard v2.0.1 was released in December 2017 to address issues discovered with v2.0 in field use. The changes are entirely non-breaking, additive-only updates. The changes should have no impact on existing API clients.

The changes were:

• DATASTD-1068 - Getting issue details... STATUS . This change extends the enumeration values for the School Year type until the 2049-50 school year.
• DATASTD-1075 - Getting issue details... STATUS . The Assessment Score collection was not included in the Objective Assessment entity, and was added as an optional collection. This issue was not a bug per se, as implementers can rely on the data in the Student Objective Assessment entity for results interpretation. However, visualizations and interpretations can be more efficient by allowing the Assessment entity to pre-define Objective Assessment scores.
• DATASTD-1103 - Getting issue details... STATUS . This change impacts XML / bulk definitions only. In order to include a core domain entity or association in an Ed-Fi Extension, the entity must have a Reference Type in the v2.0 core XSD. This change provides Reference Types for all core entities that were missing one.

Updates to the Ed-Fi Data Standard for v2.0

This section provides an overview of all the improvements, enhancements, fixes, and changes that appear in v2.0 of the Ed-Fi Data Standard. Additional detail and rationale for the changes discussed below can be found in the Data Model Changes section of this documentation.

Improvements and Enhancements

Several changes to the data standard were made to improve and enhance capabilities for implementers. This section provides a summary of the most significant changes.

Enhanced Support for Competency and Learning Objective

In the Ed-Fi Data Standard v1.2, Student Competency data was handled within a single complex type domain entity called StudentCompetency. This entity required the inclusion of a reference to a Learning Objective (LearningObjectiveReference) or a Competency Objective (StudentCompetencyObjectReference). There was also no way to identify a single Competency Objective and utilize it with multiple students. A Competency Objective would have had to be redefined each time, for every student.

In the Ed-Fi Data Standard v2.0 schema, a new domain entity was created to define a Competency Objective (CompetencyObjective). There are separate domain entities (and new complex types) to address Student Competency Objective (StudentCompetencyObjective) and Student Learning Objective (StudentLearningObjective). The StudentCompetencyObjective has a reference to the CompetencyObjective and the StudentLearningObjective has a reference to the LearningObjective. Splitting these into two different complex types helps clarify the concept of each and lessens the confusion with the structure and name. This allows for more detailed reporting in report cards and better aligns with how these concepts are treated elsewhere in the Ed-Fi Data Standard.

Improved Recording of Student Attendance

In the Ed-Fi Data Standard v2.0, AttendanceEvent has been trimmed to only have information related to specific domain attendance events. The following separate types are now available, each of which have a reference back to the AttendanceEvent:

• StudentInterventionAttendanceEvent represents the recording of whether a student is in attendance for an intervention service.
• StudentProgramAttendanceEvent represents the recording of whether a student is in attendance to receive or participate in program services.
• StudentSchoolAttendanceEvent represents the recording of whether a student is in attendance for a school day.
• StudentSectionAttendanceEvent represents the recording of whether a student is in attendance for a section.

This removes the overloading of the AttendanceEvent to represent similar, but varied concepts, and encourages reuse of event records (a single event record could be referenced by both a StudentSectionAttendenceEvent and a StudentProgramAttendanceEvent if a student were attending both simultaneously).

The Ed-Fi Data Standard v2.0 also contain a new domain entity for attendance, SectionAttendanceTakenEvent. This entity contains information around the act of recording attendance.

Specified Intent of Education Organization Reference Types

In the Ed-Fi Data Standard v1.2, EducationOrganizationReference was used in places where a more specific type and/or element was actually intended. New types have been created based on this type for School, LocalEducationAgency, StateEducationAgency, EducationOrganizationNetwork and EducationServiceCenter to further define these relationships and make it easier to understand the intent. In some cases the element itself was renamed, but in many only a type change was required.

As a result of this change, additional unique identifiers were added to LocalEducationAgency, StateEducationAgency, EducationOrganizationNetwork and EducationServiceCenter to match the pattern already established with School.

New EducationContentSource

EducationContentSource is a new complex type added to the Ed-Fi Data Standard v2.0. It shows up in Intervention, InterventionStudy, and InterventionPrescription. EducationContent.DerivativeSourceEducationContentSource also utilizes this new type, which expands on the EducationContentReference, adding additional information.

Enhanced Support for Complex School Calendars

In the Ed-Fi Data Standard v1.x, the school calendar term types natively supported by the data model were limited to an enumerated Term Type. This caused implementers with complex school calendars to extend the schema or find workarounds to support their calendar model. In the Ed-Fi Data Standard v2.0, the Term Type is replaced with a TermDescriptor in order to provide states, districts, vendors, and other users of the Ed-Fi Data Standard with the flexibility to use their own term type enumerations and code set.

Additional Flexibility in the Learning Standard Model

In the Ed-Fi Data Standard v1.2, LearningObjective and LearningStandard were included in multiple interchanges. In the Ed-Fi Data Standard v2.0, the InterchangeStandards interchange was created to handle the LearningObjective and LearningStandard data exchange and remove duplicity. When required, the external references LearningObjectiveReferenceType and LearningStandardReferenceType are included in other interchanges to reference the previously loaded LearningObjectives and LearningStandards.

Continued CEDS Alignment

The Common Education Data Standards (CEDS) initiative is a collaborative effort between the U.S. Department of Education and other federal agencies, state education agencies, local education agencies, private foundations, and vendors. CEDS produces a common vocabulary for education data, thereby streamlining data exchange and facilitating comparison across institutions and sectors. The Ed-Fi Alliance has participated in the CEDS initiative since its inception, and the Ed-Fi Data Model has contained CEDS-aligned elements since v1.1.

In January 2015, CEDS v5.0 was released. Several elements and concepts from the Ed-Fi Assessment Domain were incorporated into the new CEDS version. In addition to modifications already noted above, the Ed-Fi Data Standard v2.0 made the following CEDS-aligned additions and enhancements.

Additional Charter School Data Elements

The Ed-Fi Data Standard has been “charter-school-aware” since its inception. The Ed-Fi Data Standard v2.0 extends existing support through the School complex type by including the new optional elements CharterApprovalAgencyType and CharterApprovalSchoolYear.

CharterApprovalAgencyType, of enumeration type CharterApprovalAgencyType, captures the type of agency that approved the establishment or continuation of a charter school.  The CharterApprovalAgencyType and enumeration type values align with the published CEDS 5.0 element and option set.

CharterApprovalSchoolYear captures the school year in which a charter school was initially approved and aligns with the published CEDS 5.0 element Charter School Approval Year.

Additional Disability-Related Data Element

The Ed-Fi Data Standard v1.x Student Domain complex type contains the Disability common type which includes CEDS aligned elements that capture:

• A disability category that describes a child’s impairment
• A description of the disability (optional)
• The order of severity of student’s disabilities (optional)

To extend the CEDS alignment and support use cases, the Disability common type in the Ed-Fi Data Standard v2.0 includes a new optional element DisabilityDeterminationSourceType, of enumeration type DisabilityDeterminationSourceType, to capture the source that provided the disability determination. Additionally, the new enumeration type DisabilityDeterminiationSourceType was added to the Ed-Fi Data Standard v2.0 with enumeration values based on the published CEDS 5.0 Option Set for Disability Determination Source Type.

Enhanced Maintainability and Upgrade Support

Every version of the Ed-Fi Data Standard has attempted to balance new data model features with the cost to maintain, support, and update existing implementations. The extensive enhancements and updates in the Ed-Fi Data Standard v2.0 were implemented following this principle. Several features were implemented to enhance maintainability and upgrade support.

New Schema Element Identifier

To enable an automated version delta across future versions, the unique element identifier, EdFiId, was added to each Ed-Fi Data Standard v2.0 type and first-level child elements when applicable. The EdFiId of a given element will persist across different future versions of the Ed-Fi Data Standard.

Employed Naming Conventions

Formal naming conventions were employed when realigning, renaming, and creating elements in the Ed-Fi Data Standard v2.0. This alignment was conducted to remove confusion and increase consistency, as well as to support APIs and automated code generation. Detailed information on the naming conventions can be found on the Ed-Fi Alliance Tech Docs website: https://techdocs.ed-fi.org/display/EFDS20/XSD+Authoring+Guidelines.

Enhanced Identity, Reference, and Lookup Types

The overall identity and reference structures have dramatically transformed in the Ed-Fi Data Standard v2.0. The new schemas were architected to have a clean and repeatable model for identifying and referencing domain level elements that uniquely identify a domain entity. A new component, Lookup, is now included in those instances where the uniquely identifying elements may not be known.

Reference

The Reference encapsulates the Identity and Lookup into a single complex type.

• Naming convention: [xxx] + ReferenceType
• Includes the Identity Type (as optional)
• May include the Lookup Type (as optional)

Identity

All Identities now only have elements that are required to uniquely identify the entity. This has ramifications for the elements within an entity as well as its corresponding identity.

• Naming convention: [xxx] + IdentityType
• Consists of only the uniquely identifying elements for the entity
• All elements are required

Lookup

The Lookup enables a vehicle for use in references when not all of the identifying elements are known.

• Naming convention: [xxx] + LookupType
• Not intended to replace the identity, but includes elements from the domain entity that help “look up” identity elements
• Included in those instances where the uniquely identifying elements may not be known
• Provides a bridge to the identity type patterns from the Ed-Fi Data Standard v1.2.
• All elements are optional

Enhanced Definition of Descriptors and Extended Descriptors

In the Ed-Fi Data Standard v2.0 schemas, enhancements were made to further define descriptors and extended descriptors as well as their reference types.

The most basic of these changes is to the base DescriptorType itself. Previously the only required element was ShortDescription, but now both CodeValue and ShortDescription are required to ensure better referencing by other element structures such as the DescriptorReferenceType.

The Namespace has been converted from an attribute to an element following the tenet that attributes should contain data that’s only used in the processing of the XML (i.e., XML-internal Identifiers and References), but anything that would be expected to be saved and kept should be defined as an element.

The DescriptorReferenceType has been altered to only include the CodeValue and the Namespace. The previous method of allowing for CodeValue, ShortDescription, or Description meant a reference using CodeValue or Description would fail if only the ShortDescription was saved in the Descriptor itself. This change also satisfied that directive of only using elements that uniquely define the record.

Specific types have now been created for each descriptor reference that serves as an extension to the base descriptor reference type. Previously a descriptor reference element would just use the base type called DescriptorReferenceType directly in each instance of the element. In the Ed-Fi Data Standard v2.0 schemas, a new Type is created that is an extension of DescriptorReferenceType. It has no new elements and essentially functions as an alias for the DescriptorReferenceType. While this change has little bearing on viewing of the XML itself, the separate types allow for more advanced external processing since each descriptor is now truly individually defined.

This change has given rise to a modification in the way some extended descriptors are defined as well. Common types have been created in cases where additional information is needed or available. As an example, the Language common type consists of a Language element of type LanguageDescriptorReferenceType and an optional LanguageUse element. This common type can now be used in place of the standard Descriptor Reference. In the Ed-Fi Data Standard v1.2, this concept was represented in the LanguageUseDescriptorReferenceType. The same logic has been implemented in Behavior, CalendarEvent and other extended descriptors.