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:

Code Characteristic
M Mandatory element or attribute
O Optional element or attribute
C Conditional element or attribute
MR Mandatory and repeatable element
OR Optional and repeatable element
CR Conditional and repeatable element

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.

SIF Adapters and message brokers MUST supply data according to the types specified in the Type columns and their corresponding equivalents in the most recent schema files associated with this specification. If there is a discrepancy between object and element definitions in this specification and the corresponding schema files, the definition in the schema files takes precedence; every effort will be made to note discrepancies in the errata for this document as they are identified.

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. See section 4 for more detailed information and the model itself.

3.1.3 Conventions Object Attributes/Primary Keys

While XML attributes are primarily used in SIF to provide additional processing information regarding the associated element content, attributes at the root level of an object have special significance. These attributes serve as the primary key or identifier for the object; in all cases this is no more than a RefId GUID of RefIdType 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: 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.:

{ "EmailList": { "Email": [ { "Type": "01", "value": "contact@sifinfo.org" }, { "Type": "02", "value": "info@sifinfo.org" } ] } }
<EmailList> <Email Type="01">contact@sifinfo.org</Email> <Email Type="02">info@sifinfo.org</Email> </EmailList>
Example EmailList List

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

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.

{ "CountriesOfCitizenship": { "CountryOfCitizenship": [ "1101", "2304" ] } }
<CountriesOfCitizenship> <CountryOfCitizenship>1101</CountryOfCitizenship> <CountryOfCitizenship>2304</CountryOfCitizenship> </CountriesOfCitizenship>
Example Indicating an updated list of country citizenships

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

3.1.4 Validation Supported Optional Elements Without Values

Some agents follow the convention of supplying an optional element as empty (e.g. <BirthDate></BirthDate> or <BirthDate/> to indicate that the application supports the element, but that it currently has no value available within a given object. To allow for this convention within SIF—as in this example an empty string does not satisfy the xs:date type definition of BirthDate—all optional elements in SIF are defined as nillable [SCHEMA]. To satisfy type constraints on an element while still supplying an empty or "nil" value, agents MUST tag the element with a true value for the nil attribute from namespace http://www.w3.org/2001/XMLSchema-instance [SCHEMA] (e.g. <BirthDate xsi:nil="true"/> where the prefix xsi has been mapped to the namespace http://www.w3.org/2001/XMLSchema-instance), unless an empty value is valid with regard to the element's type definition, in which case supplying the nil attribute value of true is optional. 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. Payload Validation

There are two sets of XSDs available for Validation of Payload. 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. 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 addition, 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. JSON Validation

No Validation mechanism/schema is currently defined for SIF JSON, but that SIF JSON is intended to be a one-to-one mapping from SIF XML 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.

Valid XHTML 1.0 Transitional