# 2 Introduction

## 2.1 Specification Organization

With respect to the SIF Specification, educators and non-technical readers are typically interested in the pK-12 data objects that can be shared and reported on by SIF-enabled applications in SIF implementations. This document, the SIF Data Model Implementation Specification, contains a Data Model section in a format that should not be a barrier to readers with some knowledge of [XML]. More technical readers, including software architects, developers and integrators, will also be interested in the separate SIF Infrastructure Implementation Specification document.

- The Preamble provides an abstract of SIF along with the SIF Association disclaimer and details regarding certification and compliance claims.
- This Introduction outlines the organization of this specification document, provides conventions used in this document, and summarizes versioning of the specification. Highlights of additions/changes since the previous version of the specification are also provided.
- The Data Model section provides definitions of the XML structure for common elements in the data model and all objects related to entities in the pK-12 environment. This section is organized by the working groups and task forces within the SIF Association that have defined common elements or objects.
- The document concludes with various appendices including lists of code set values defined within SIF and in external documents, and ends with a list of references to other documents.

## 2.2 Document Conventions

### 2.2.1 Definitions

The first time a term or concept is defined, it may be emphasized.

### 2.2.2 Structure and Values

`SIF message and object names, XML element tags, attribute names and values, and other codes or values are typically presented as in this sentence.`

### 2.2.3 Examples

JSON
{ "xml": "Longer examples of XML,JSON or HTTP messages are typically numbered and presented as given here." }
XML
Longer examples of XML,JSON or HTTP messages are typically numbered and presented as given here.
Example 2.2.3-1: Examples Convention

### 2.2.4 JSON

Java Script Object Notation (JSON) is an alternate way to represent an object in a tree like structure. JSON is desirable for a variety of reasons including: good wire efficiency, strong programming support, and satisfactory human readability. Since SIF’s data models are formally defined using XML Schemas, JSON conversion is handled through one of two sets of rules.

`Default:` Goessner Notation, which uses schema-independent generic rules for ease of translation. [Goessner JSON]

`Preferred:` PESC JSON which uses schema-aware rules for consistent results. [PESC JSON]

### 2.2.5 References

References to other works occurring in this text are given in brackets, e.g. [REFERENCE]. The text in brackets corresponds to a key in the References appendix. Often when the text in the brackets duplicates surrounding text, the reference alone is used (e.g. [XML] instead of XML [XML]).

### 2.2.6 Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL, when EMPHASIZED, are to be interpreted as described in [RFC 2119].

### 2.2.7 XML Diagrams

Quick overviews of XML structures, including messages, objects, common elements and types, are provided in XML diagrams. The following diagram illustrates the conventions typically encountered in SIF.

Figure 2.2.7-1: XML Diagram Conventions

XML elements are represented by rectangles with the name of the element in the upper portion and the type, if any, in the lower portion. Attributes are represented in the same fashion, but have an `@` icon rather than a SIF icon. Elements and attributes that are optional have a circled `?` (0 or 1 occurrence) to the left of the rectangle. Optional and mandatory repeatable elements are indicated by a circled `*` (0 or more occurrences) and `+` (1 or more occurrences), respectively. Element attributes are grouped together in a rectangular block and connected to the element with a line that turns at right angles. Ordered sequences of XML elements are bracketed by lines that turn at right angles. When a choice of XML elements is indicated, the elements are bracketed by angled lines. A choice of elements can occur within an element, or may be an unnamed choice of elements.

XML types are represented using the same conventions as for XML elements, though the type portion of the rectangle typically indicates a base type, if any.

The type name of any element, attribute or type may be prefixed with a `↓`, indicating the type is restricted in some fashion by one or more XML Schema facets (e.g. enumeration). When the type is a union of types, a list of types is presented, each type separated by `|`; if the list of union types is long, the list may be marked with ellipses, e.g., `| ...`

In an actual XML diagram, element, type and attribute rectangles are usually linked to their corresponding definitions/descriptions in accompanying tables.

## 2.3 Version Numbers

The SIF Implementation Specification uses the following version numbering scheme:

major version `.` minor version `.` revision number `(X.Y.Z)`

Once a versioned specification (Specification Release) has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released under a new Specification Version Number unless the modification is the correction of an error or update of documentation. Each Specification Release has an associated errata section in which modifications and corrections of the release are listed.

A Specification Version Number for a Specification Release uses conventions as follows:

- A Specification Version Number MAY take the form `X.Y.Z` where `X`, `Y`, and `Z` are nonnegative integers (whole numbers), and MUST NOT contain leading zeroes. `X` represents the Major version, `Y` represents the Minor version, and `Z` represents the Revision version.
- Each version number element MUST increase sequentially based on the guidelines defined within this document; for instance, `1.9.1` to `1.10` to `1.11` to `1.11.1` .
- Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into major, minor, revision identifiers in that order. Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, Minor, and Revision versions are always compared numerically; for example, `1.0.0` < `2.0.0` < `2.1.0` < `2.1.1` .

An instance of a Specification Version Number is the canonical identifier for a Specification Release. The manner in which the Specification Version Number increments after a given Specification Release depends on the type and relative magnitude of changes being proposed in the new release as follows:

1. The Revision version number ( `Z` in x.y.`Z`, where `x` >= 0) MUST be incremented when specification changes are limited to backward compatible changes. If `Z`=0 then the convention is to drop the Revision number: for example, `3.1` instead of `3.1.0`. Backward compatible changes include the following:

- New data object.
- New optional data object element.
- New optional utility service object element.

2. The Minor version number ( `Y` in x.`Y`.z, where `x` > 0 ) MUST be incremented if new functionality is added to the specification. It MUST be incremented if any aspect of the specification is marked as deprecated. It MUST be incremented if any aspect of the specification is not backward compatible. (Backward compatible means any change that can be implemented by one participant (consumer, Environment or service provider) without requiring changes by other participants to maintaining the same level of interoperability.) It MAY be incremented if substantial new functionality or improvements are introduced. It MAY include changes that are categorized as ”Revision” level magnitude. The Revision version MUST be reset to 0 when the Minor version is incremented. Changes requiring a Minor version increment include the following:

- New mandatory data object element.
- New mandatory utility service object element.
- Deprecate data object element.
- Deprecate data object.
- Deprecate utility service object element.
- Deprecate utility service object.
- Remove deprecated data object element.
- Remove deprecated data object.
- Remove deprecated utility service object element.
- Remove deprecated utility service object.
- Add support for additional authentication methods.
- Add support for additional TLS version.
- Any changes concerning security.
- Any optional to mandatory change.
- Add support for additional payload representations.

3. The Major version number ( `X` in `X`.y.z, where `X` > 0 ) MUST be incremented if a significant change is introduced to the specification. It MAY include changes categorized as Minor and Revision level changes. The Revision and Minor version numbers MUST be reset to 0 when the Major version is incremented. Changes requiring a Major version increment include the following:

- Deprecate payload representation.
- Remove deprecated payload representation.
- Add support for a distinct data model namespace.
- Replace (deprecate and remove) a locale data model.
- Any significant change that requires the Major version to be incremented as deemed by the A4L Association Board for global specifications and Management Boards for locale data models.

## 2.4 Highlighted Additions/Changes

This release contains the following significant updates and extensions to the SIF specification.

### Additions/Changes since 3.4.8 March, 2021

#### New Objects

- PersonPrivacyObligationDocument object added for this release. This object contains information about the person's data and privacy obligations as well as permissions and consent associated with it.

#### New Elements

- `SchoolInfo/ParentCommonwealthID`, requested by ACARA: used to differentiate the original Australian Government school identifiers, which applied to school locations, from the new Australian Government school identifiers as of 2021, which only apply to schools.
- `StudentPersonal/NationalUniqueStudentIdentifier`, requested by QLD DoE: support of national Unique Student Identifier initiative.
- `StudentPersonal/IndependentStudent`, requested by QLD DoE: identifty students responsible for their own education.
- `DemographicsType/Passport`, requested by QLD DoE: support for international students.
- `DemographicsType/VisaNumber`, `DemographicsType/VisaGrantDate`, `DemographicsType/VisaStudyEntitlement`, `DemographicsType/VisaCondtions`, requested by QLD DoE: support for international students. (Information sourced from VEVO.)
- `StudentContactPersonal/Employment`, `StudentContactPersonal/Workplace`, requested by QLD DoE: student background data collection.
- `Debtor/BSB`, `Debtor/AccountNumber`, `Debtor/AccountName`, requested by QLD DoE: charging parents and guardians with school fees.
- `StudentContactPersonal/WorkingWithChildrenCheck`, requested by QLD DoE: confirm eligibility of student contacts to perform ad hoc work on behalf of school (e.g. homestays).
- `StudentContactRelationship/FeePercentage`, requested by QLD DoE: capture proportion of student fees paid by a particular student contact.
- `StudentContactRelationship/ContactMethod`, requested by QLD DoE: preferred method of correspondence for a student contact in relation to a student.
- `DemographicsType/MedicarePositionNumber`, `DemographicsType/MedicareCardHolder`, `DemographicsType/PrivateHealthInsurance`, requested by QLD DoE: capture medical insurance information about students.
- `WellbeingCharacteristic/PreferredHospital`, requested by QLD DoE: capture medical care arrangements for a particular medical condition for a student.
- `StudentSchoolEnrollment/IntendedEntryDate`, requested by QLD DoE: capture date that student is intended to enrol, as distinct from the date that they actually enrol.
- `WellbeingEvent/FollowUpActionList/FollowUpAction/Date`, requested by QLD DoE: capture date that a follow up action in student wellbeing occured.
- `StudentGrade/TermSpan`, `StudentGrade/SchoolYear`, requested by QLD DoE: capture temporal scope of a student grade.
- `CensusCollection/LocalCodeList`, added for consistency with rest of data model.
- `CampusContainerType/ParentSchoolRefId`, requested by CEO Melbourne, to allow SchoolInfo object for a campus to be linked via RefId to a SchoolInfo object for a parent school.

#### New Types

- `WorkingWithChildrenCheckType`, requested by QLD DoE, further suggestions from Systemic: encode eligibility to perform work wth children on behalf of school (e.g. homestays)
- `StudentContactFeePercentageType`, requested by QLD DoE: encode proportion of student fees paid by a particular student contact
- `PrivateHealthInsuranceType`, requested by QLD DoE: encode private medical insurance information

#### New CodeSets

- `Visa Study Entitlement`, requested by QLD DoE: support for international students. (Information sourced from VEVO.)
- `Contact Method`, requested by QLD DoE: communications media for contacting persons.

#### Additions to CodeSets

- Addition to `School Level`—`SpecialAssistance`, requested by CEO Melbourne: aligned with Education Act. Accounts for discrepancy in Census reporting: these are Special schools as listed by ACARA, but they have regular year levels unlike Special schools.
- Addition to `Attendance Code`—`626`, `Prep Transition day`. Used to capture day that Prep students are not required to be in attendance, as part of Prep Transition.
- Addition to `Federal Electorates`—`219` (Hawke). Codes for Victoria renumbered following ABS practice. `514` (Stirling) will be retained until it is abolished at the next federal election.
- Addition to `ISO 4217 Currency Names And Code Elements`—`UYW, VED`, added to ISO 4217.

#### Other Changes

- Change to label of codeset `OperationalStatus` value `P`, from `Pending` to `Proposed`.

#### Corrections