{"sample": "Longer examples of XML or HTTP messages are typically numbered and presented as given here." }
With respect to this SIF Specification, decision makers are typically interested in the capabilities and designs largely present in the Base Architecture volume. This document, the SIF Infrastructure Specification, contains an Infrastructure section describing the payloads used in a format that should not be a barrier to readers with a some knowledge of [XML]. More technical readers, including software architects, developers and integrators, will also be interested in all the separate Infrastructure volumes.
The first time a term or concept is defined, it may be emphasized.
SIF message and object names, XML element tags, attribute names and values, and other codes or values are typically presented as in this sentence.
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]).
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].
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.
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.
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:
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.1.9.1 to 1.10 to 1.11 to 1.11.1 .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:
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:
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: