Composing Custom Interchange Schema

Ed-Fi Interchange Schemas define the structure of the XML that transports the data between systems, as shown below. Interchange schemas can contain as much or as little data as required. In most cases, different interchange schemas will be used to reflect different use cases or to deal with different periodicities of interchange.

Ed-Fi Interchange Schemas

The Ed-Fi Data Standard v2.2 contains a set of 21 Standard Interchange Schemas. These represent field-tested schemas based on the un-modified, non-extended Ed-Fi Core XML Schema to handle many common data exchange use cases. (See the section Ed-Fi Standard Interchange Schema for background information and a list of pre-composed schema.)

The Ed-Fi Core XML Schema provides a library of building blocks from which to compose interchange schemas, as depicted in the diagram below. Ed-Fi Interchanges are constructed by referencing the complex types for domain entities, Descriptors, and associations.

However, implementations often have use cases beyond those covered by the Standard Interchange Schemas. This section provides guidance to technical personnel on applying the Standard to create custom interchanges.

Considerations

In creating interchanges using the Ed-Fi Data Standard, there are several additional considerations that may require additional analysis, including:

• Security and FERPA issues. Based on the users of the receiving system or data store, data may need to be filtered or redacted prior to interchange. For example, a district should only be able to see student data for students enrolled in their district.
• Periodicity of interchange. Since most data interchanges are in response to recurring requirements, the periodicity of the interchange must be considered. For example, attendance data may be interchanged daily, where the scores to standardized tests may only be loaded after administration.
• Incremental changes vs. bulk updates. Whether complete data sets will be transferred or just the changes will impact the data being interchanged. Transferring only the changes will greatly reduce the bulk of data to be processed, but will require additional complexity on both sides of the interchange to detect and appropriately handle the changes. Bulk updates are much simpler, but require much larger transfers.
• Reliability of identity references. When extended reference types are used to pass identity information for lookup (e.g., students), the reliability of the data and the algorithms used to match instance identities must be considered. For example, is enough data provided to verify identity when matched by a primary ID? If a primary ID is erroneous, is enough data provided to uniquely match on other attributes?
• Consistency between multiple information sources. When data is accepted from multiple sources—for example, between different student information systems from different LEAs—there may be inconsistencies in the data that may require special attention, such as different enumeration lists values or different naming conventions.

How-To Articles and Examples

Detail on how to compose a custom interchange schema can be found on the following pages: