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 Conventions

3.1.2.1 Object Attributes/Primary Keys

3.1.2.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.2.3 Lists/Repeatable Elements

For those accustomed to normalized relational databases, the SIF Data Model will appear to be not especially normalized, especially with regard to repeating groups of data not 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 Zone. 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 Zone. 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.:

Two types of list are currently defined in SIF, ActionList and List; both consist of a list container element and a single repeatable child element. Each type of list serves different needs and has associated conventions for communication and processing in the SIF Publish/Subscribe Model. List or ActionList is specified in the Type column in tables in this section for each list; when an ActionList the key, possibly compound, is also indicated in the Type column. ActionList key values must be unique within an instance of an ActionList.

3.1.2.3.1 ActionList

An ActionList has a key that uniquely identifies each child element within the list. This type of list is primarily used when it is desirable or necessary for systems to support or refer to a subset of the list, either due to functionally only being able to support a subset or because specifying a subset in Change events is more efficient than transmitting a whole list as in List. While one system may support the School and Personal e-mail address types above, another may additionally support Alternate1 addresses. The second system is able to communicate the addition, change or deletion of an Alternate1 address without the first system inadvertently interpreting that to mean a student or staff member's School and Personal addresses have been deleted.

Systems communicate the whole list as a cohesive unit consisting of the parent list container element and all child elements in an Add event; if the container is present with no child elements, the list is empty; the same is implied when an optional list is not present in an Add event. In a Change event, systems SHOULD only transmit those elements that have been added, changed or deleted. Deletion is not implied by the omission of a child element, but rather explicitly communicated with a SIF_Action attribute of Delete added to the deleted element, along with the element's key attribute(s)/element(s) at a minimum. An empty list in a Change event implies no changes have occurred in the list, as does the omission of the list. Systems storing ActionList data should set/replace/delete any existing values identified by primary keys in the Change event they support.

A system that supports an Alternate1 e-mail makes no changes to its value for that address type.

3.1.2.3.2 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 United Kingdom and German citizenship.

3.1.2.4 Supported Optional Elements Without Values

3.1.2.5 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.2 Common Elements