This section presents the XML structure for SIF common elements and objects in a tabular format for readers less versed in parsing formal XML schema definitions, along with conventions that typically apply for easy reference.
The Char(acteristics) column for all 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.
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 id GUID of uuidType
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.
There are two sets of XSDs available for Validation of Payload.
The first set, called "DataModel" or "Strict" 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.
The second set, called "SIF_Message" or "Lax" is 'lax' and every element within the schema is 'optional' except the 'Id' 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 Id/UUID only, the consumer must assume that object to be DELETED or that it has been deleted since the original request was made.