Ed-Fi Core XML Schema Overview
The Ed-Fi Core XML Schema is the direct embodiment of the Unifying Data Model in an XML schema format that is designed to meet the requirements for XML data interchange, and has the following attributes:
- A core set of domain, association, and attribute types that directly map to the Unifying Data Model
- A method and examples of composing interchange schemas, reusing the types defined in the core schema
- A method and examples for extending the core schema and interchange schema to account for implementation-specific, or even interchange-specific, data (discussed in the Ed-Fi Extension Framework section of this documentation)
Ed-Fi Core XML Schema Expresses the UDM
The Ed-Fi Core XML Schema expresses the Unifying Data Model’s entities, associations, and attributes for education data. The Ed-Fi Unifying Data Model is organized into 16 domains. These domains are organized into 59 different entities and 22 associations, and supported by 50 Descriptors—all of which have representative XML schema complex types.
XML schemas enforce rules around the content of XML-instance documents. However, there are many different ways and styles for XML schemas to accomplish the same goal.1
The Ed-Fi Core XML Schema is designed with the following principles:
- Consistency. The XML schema should have a consistent organization and design pattern.
- Extensibility. The XML schema should be designed to easily allow for customizations to meet specific interchange requirements.
- Flexibility. The XML schema should be flexible to support the interchange of different subsets and collections of education data.
- Reuse. The XML schema should be designed to facilitate the reuse of types of elements in constructing the interchange schemas used for data transfer.
- Composition Using XML Mechanisms. The creation of interchange schemas from core and extended schemas should be accomplished using native XML mechanisms, not through a cut-and-paste operation.
Schema Design Pattern
The Ed-Fi Core XML Schema uses the Venetian Blind design pattern to facilitate reuse while also hiding namespace complexities. For each interchange schema, the style defines a single global element that nests local elements that use types (simple or complex) that are defined within the global namespace. For example, consider the interchange schema for parents and their student relationship depicted below.
A single element InterchangeParent defines the interchange. The two elements of the interchange, Parent and StudentParentAssociation, are nested within the single element, referencing types in Ed-Fi-Core.xsd (see the
include statement above).
To provide maximum flexibility for the interchange, we chose to encapsulate the elements of the interchange in an unbounded
choice statement rather than in an XML
sequence. As a result, the various elements of the interchange are optional and can be provided in any order.
Versions of the Ed-Fi Core XML Schema are identified by major and minor version number, such as “2.1”. A version may be appended with RFC ("Release for Comment"), RC ("Release Candidate"), or DRAFT. Versions are identified by the following:
- A unique default namespace
- A unique location for the file on the web
The Ed-Fi Core XML Schema identifies the target namespace
(with an appending version) as the default namespace. This is done so references to complex types do not have to qualify each reference, hence improving readability.
The implication is that any interchange (or customized core schema) that references the Ed-Fi-Core.xsd would need to use the same namespace, as shown here:
Ed-Fi Core XML Schema Organization
The primary Ed-Fi Core XML Schema types listed below are the building blocks of interchange schemas. The domain entities and associations match exactly those in the UDM.
Table 2. Ed-Fi Core Schema Primary Types
XML complex types representing the major entities in the education domain, as modeled in the Ed-Fi Unifying Data Model.
XML complex types representing enumerations that cannot be standardized, and are determined by the content of their application and require loading in an interchange.
XML complex types representing those associations between the domain and Descriptor entities that require attributes.
Domain entities, Descriptors, and association types are composed from a second tier of XML simple and complex types and are organized as follows:
Table 3. Ed-Fi Supporting Types
Template structures for entities, Descriptors, reference types, and Descriptor reference types.
Extended reference types
Supporting associations via XML
Extended Descriptor reference types
Referencing the Descriptor values for an attribute.
Complex types composed of cohesive records of attributes, such as Name, Address, or Telephone.
Standard code lists or controlled vocabulary that are used for attributes or are used to map Descriptor values.
String simple types and Numeric simple types
Strings, integers, and doubles with specific constraints, such as length or value range, for the various simple typed attributes. While strings can be restricted in-line, this approach creates an anonymous type that can cause trouble when extending the parent complex type. Therefore, all restricted types are named..
All domain entities are XML extensions of the type ComplexObjectType. This type defines the common ID attribute that holds the assignment of an XML
IDREF to instances of the domain type used in interchange schemas, as shown below.
The complex type for the domain entity corresponds to the class defined in the UDM. The elements of the complex type correspond to the attributes of the UDM class, as shown in the following example for CourseOffering:
Following the tenet that XML attributes contain data that is only used in the processing of the XML, the ComplexObjectType, and ReferenceType base types provide the XML-internal Identifiers, as shown below.
Generalizations are specified using the XML schema extension. For example, EducationOrganization is a generalization of School, LocalEducationAgency, EducationServiceCenter, EducationOrganizationNetwork, and StateEducationAgency as shown below. Conversely, it can also be said that School is a specialization of EducationOrganization.
The complex type EducationOrganization is identified as an abstract type denoting that it is only defined as a generalization and may not be used on its own.
Specializations are reflected as extensions of the base type, specifying the additional elements particular to School, as shown below. Note that School inherits all of the attributes of EducationOrganization.
Developers' Guide Documentation Contents
Find out more about how to develop solutions based on the Ed-Fi Data Standard v2.0: