3 Data Model

3.1 Introduction

This section presents the XML structure for SIF Data Model common elements and objects in a tabular format for readers less versed in parsing formal XML schema definitions, along with conventions that typically apply in the data model for easy reference.

3.1.1 Format

The Char(acteristics) column for all of the tables in this section use the following codes:

Mandatory elements MUST be present in Add events, and in non-empty and non-error responses to requests for entire SIF objects (e.g., no SIF_Query/SIF_QueryObject/SIF_Element elements supplied in the request). Mandatory attributes MUST always be present if their corresponding element is present.

3.1.2 Conceptual Modelling

The SIF AU Data Model is a “data in motion” model, which has been designed for data exchange between institutions. However, it is increasingly being used within enterprises, and it has been widely used as a nationally agreed data model for education. In order to help navigate the SIF data model better, and to make it easier to map between SIF and other data models of education, we have abstracted a conceptual data model from SIF AU, treating SIF AU as a logical data model. The document Conceptual Model v0.5.pdf (11/07/2019) outlines the current conceptual model for SIF AU, and how it maps to the logical model.

3.1.3 Conventions

3.1.3.1 Object Attributes/Primary Keys

3.1.3.2 Object References

As stated elsewhere, SIF primarily uses GUIDs as object identifiers, primary keys, or RefIds. References to primary keys (foreign key references) follow certain conventions in SIF in most objects:

3.1.3.3 Lists/Repeatable Elements

To those accustomed with normalized relational databases, the SIF Data Model will appear to not be especially normalized, especially with regard to repeating groups of data not being separated into their own "tables," or in SIF's case, "objects" with primary/foreign keys to maintain the relationship. Bear in mind that SIF is not a format for storing data; it is a format for transmitting data asynchronously between disparate and distributed systems needing to share data for interoperability; the format this data takes in different systems can vary greatly, and the data related to any given "entity" may come from a variety of sources and systems. The goals of normalization—eliminating redundancy, organizing data efficiently, reducing inconsistencies, etc.—take on a different meaning in a message queuing system. Of primary importance is transmitting the data needed for interoperability in a minimum number of messages. The need to "join" together a great number of separate objects is kept to a minimum in SIF, as individual systems do not have access to all the data required and due to the asynchronous nature of SIF, any one of these systems may take a fair amount of time before returning data necessary for joins (SIF_ExtendedQuery has been developed to communicate a join to a single system that may have direct access to the all the data necessary to efficiently accomplish this task). It's one thing to make a separate request for a student's picture or enrollment information, another entirely to request every available phone number, address and e-mail address separately from the SIF Environment. As such, it is often the case in SIF that repeating data is stored directly in an object, rather than being separated out into a separate object.

Repeating data is very analogous to objects, though, within any given object. In SIF's Publish/Subscribe model, repeating elements in objects can be added to, changed in or deleted from an object, much like objects can be added to, changed in or deleted from a SIF Environment. Within an existing object, all of these actions take place within a Change event, and repeating elements—if any exist initially—are first made available within an object in an Add event or can be obtained directly via requests. Repeatable elements are contained within a parent List element in most SIF objects whether or not they support events, e.g.:

3.1.3.3.1 List

While a unique, primary key may still be identifiable in its child elements, a List is used primarily when:

• the list is a cohesive whole conceptually, where supporting or referring to a subset of the list is of little value;
• when the list consists only of keys, and no associated data;
• the list is informational/temporary state information and not typically persisted; or
• when no key exists to uniquely identify items in the list.

Lists are always transmitted as a cohesive unit consisting of the parent list container element and all child elements. If no child elements exist in the list, the list consists of the container element alone. Omission of an optional List in an Add event also implies no list items. In a Change event, omission of the List indicates no changes have been made; otherwise the parent container element and all child elements, if any, are included. Systems storing List data should replace all corresponding data in their systems when persisting the list; likewise when a change is made to one or more list items or when all items in the list are deleted, systems should send the whole list in a Change event.

A system that supports CountriesOfCitizenship updates its local data to reflect Australia and German citizenship.

3.1.4 Validation

3.1.4.1 Supported Optional Elements Without Values

3.1.4.2 Externally-Defined XML

Note that XML not defined within SIF does not necessarily support ad hoc omission of XML elements at will to conform with the conventions of the SIF Publish/Subscribe Model (where unchanged elements are typically omitted in Change events, and where non-key elements are often omitted in Delete events) or of the SIF Request/Response Model (where a subset of elements can be retrieved from objects with requests). If externally-defined XML occurs within a SIF data object, SIF conventions do not extend to that XML unless that XML is defined to accommodate SIF conventions; the XML, when transmitted, must only conform to any external definitions dictating its structure, if any. Applications should be prepared for the possibility of receiving whole externally-defined XML structures in Change events (regardless of how little or much of the external XML has changed) and possibly also Delete events, likewise in responses even when a subset of the XML structure's child elements may have explicitly been requested.

3.1.4.3 Payload Validation

There are two sets of XSDs available for Validation of Payload.

3.1.4.3.1 Create

The first set, "DataModel" is 'strict' and all of the elements that are required for validation are 'Mandatory' in this suite of XSDs. This suite is traditionally used for Creation of new entities, which generally require validation before being saved into a Data Store.

3.1.4.3.2 Update

The second set, "SIF_Message" is 'lax' and every element within the schema is 'optional' except the 'RefId' the identifying GUID/UUID. (However, required elements are not nillable.) This suite of XSDs are traditionally used for Update and Delete of current entities. If an element is not included in the payload of an Update operation, its value is assumed to be unchanged. In additon, if the payload contains the RefId/UUID only, the consumer must assume that object to be DELETED or that it has been deleted since the original request was made.

3.1.4.3.3 Local Code Set Validation

In SIF AU 3.4.5 we introduce a method of augmenting code sets with local values without 'breaking changes'. Future releases will add "OtherCodeListType" to each code set and in-line enumerations will also be typed to allow for extensions. Every Object in SIF AU 3.4.5 has a LocalCodeType which will allow extensions to, but does not replace, current validation set. The following document outlines the need and the interim solution.