How To: Create a Custom Interchange (Part 1 - Overview)

This section provides guidance for organizations adopting the Ed-Fi XML Standard on how to create interchange schemas from the Ed-Fi-Core.xsd.

Analytic Process Overview

For a specific education data interchange requirement, applying the Ed-Fi Data Standard requires identifying the specific data requirements for the interchange and then creating an appropriate interchange schema to meet that requirement. The steps associated with creating an Ed-Fi Interchange Schema are as follows:

1. Analyze the specific data requirements for the data interchange.
2. Analyze the specific interchange transactions that are required.
3. Map the data requirements to the Ed-Fi Unifying Data Model.
4. Identify the Ed-Fi domain types and association types required for the interchange.
5. Ensure that the receiving system is capable of performing required lookups for references to specific instance of education data not part of this interchange.
6. Create the interchange schema file(s) to match the various interchange transactions, referencing the core types required for the interchange.

Technical Process Overview

Specific data exchange schemas are composed of a choice of elements selected from the domain and association types available in the Ed-Fi Core.

The steps involved in creating an interchange schema are as follows:

1. Create a separate XML schema definition file for the interchange schema.
2. Use the XML include statement to reference the Ed-Fi Core XML schema.
3. Create a single new element for the interchange.
4. Insert an unbounded XML choice statement.
5. Within the choice, insert elements referencing the desired Domain Entities, Descriptors, or Associations required for the interchange.

Generally speaking, there are two types of interchange schema: those that are self-contained and those that have external references. A brief discussion of each type follows.

Self-Contained Interchange Schemas

Depending on the data required, some data interchanges may be self-contained, meaning that the classes of data, plus all of its associations, are contained within the same single interchange.

For example, consider the interchange for students based on the Ed-Fi Core. The interchange for Student is composed from the complex type for the Student domain entity class, as shown below.

InterchangeStudent

<?xml version=”1.0” encoding=”UTF-8”?>
<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns=”http://ed-fi.org/0210” targetNamespace=”http://ed-fi.org/0210” elementFormDefault=”qualified” attributeFormDefault=”unqualified”>
	<xs:include schemaLocation=”Ed-Fi-Core.xsd”/>
		<xs:complexType>
			<xs:choice maxOccurs=”unbounded”>
				<xs:element name=”Student” type=”Student”/>
			</xs:choice>
		</xs:complexType>
	</xs:element>
</xs:schema>

Interchange Schemas with External References

Some data interchanges may include external references to entities that are assumed to already be loaded by the receiving system.

For example, consider a data interchange to load parent information and the familial relationship between the student and the parent. The interchange schema requires the Parent and StudentParentAssociation entities, as shown below.

InterchangeParent

<?xml version=”1.0” encoding=”UTF-8”?>
<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns=”http://ed-fi.org/0210” targetNamespace=”http://ed-fi.org/0210” elementFormDefault=”qualified” attributeFormDefault=”unqualified”>
	<xs:include schemaLocation=”Ed-Fi-Core.xsd”/>
	<xs:element name=”InterchangeParent”>
		<xs:complexType>
			<xs:choice maxOccurs=”unbounded”>
				<xs:element name=”Parent” type=”Parent”/>
				<xs:element name=”StudentParentAssociation” type=”StudentParentAssociation”/>
			</xs:choice>
		</xs:complexType>
	</xs:element>
</xs:schema>

An inspection of the required elements for StudentParentAssociation (see below) reveals that the StudentParentAssociation has a mandatory, external StudentReference reference.

This interchange assumes that the system receiving the data has already loaded students. The appropriate extended reference types (discussed previously) define the attributes required to uniquely identify the specific student associated with the parent.

<xs:complexType name=”StudentParentAssociation”>
    . . .
	<xs:complexContent>
		<xs:extension base=”ComplexObjectType”>
			<xs:sequence>
				<xs:element name=”StudentReference” type=”StudentReferenceType”>
                . . .
				<xs:element name=”ParentReference” type=”ParentReferenceType”>
                . . .
				<xs:element name=”Relation” type=”RelationType” minOccurs=”0”>
                . . .
				<xs:element name=”PrimaryContactStatus” type=”xs:boolean” minOccurs=”0”>
                . . .
				<xs:element name=”LivesWith” type=”xs:boolean” minOccurs=”0”>
                . . .
				<xs:element name=”EmergencyContactStatus” type=”xs:boolean” minOccurs=”0”>
                . . .
				<xs:element name=”ContactPriority” type=”xs:int” minOccurs=”0”>
                . . .
				<xs:element name=”ContactRestrictions” type=”ContactRestrictions” minOccurs=”0”>
                . . .
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>