Appendix D: Notes on Related Technologies

SIF uses a small subset of HTTP 1.1 (SIF HTTP), as defined in Infrastructure Transport Layer , to promote interoperability. This section also defines a secure transport for SIF HTTP, SIF HTTPS, the required and default transport layer for use in SIF.

Zone Integration Servers and Push-mode Agents, when using SIF HTTPS or SIF HTTP, are addressable by an http or https Uniform Resource Locator (URL). As far as HTTP is concerned, these are simply formatted strings; no assumptions should be made about their format (e.g. that all ZIS URLs consist of a host, port and Zone ID, or that all agent URLs consist of a host, port and Agent ID) beyond the http and https schemes and the consituent parts from the generic URI (Uniform Resource Identifier) syntax [RFC 2396].

http:// host[:port][abs_path[?query]]
http://host[:port][abs_path[?query]]

Just because one Zone Integration Server seems to follow a certain convention with regard to its URLs, e.g.:

http://www.YourZIS.com/YourZone

does not imply another Zone Integration Server will not have a completely different format for a URL, for instance:

http://www.ZISesAreUs.com:8080/applications/ZIS;version=2.3.1?zone=ZoneA&cust=2A9823B2

or that a vendor's product might not change its URL conventions.

The same applies to URLs that address Push-mode Agents; conventions for URLs, within the general formatting that applies to URLs, can and do vary widely.

Zone Integration Servers and Agents MUST treat SIF HTTPS and SIF HTTP URLs as whole strings, whose only format rules stem from associated standards. This promotes interoperability as Zone administrators deploy Zone Integration Servers and Agents with different Zone configurations and products from different vendors.

With its use in both Infrastructure and the SIF Data Model, SIF is greatly dependent on the structure and syntax of XML 1.0 [XML]. SIF excludes the use of the doctypedecl syntax from the optional prolog with which every XML document may begin. This implies that Zone Integration Servers and Agents MUST NOT reference an external DTD or internal DTD subset using the doctypedecl production (e.g. <!DOCTYPE SIF_Message ... !>).

This should not be construed to imply that the rest of the XML prolog may not preface a SIF message, even though it never occurs in examples within this specification, being superfluous within SIF. As SIF mandates the use of XML 1.0, the character encoding of UTF-8 (contained in the HTTP Content-Type header), and all SIF messages are standalone due to the exclusion of doctypedecl above, the values that can be communicated in the XML prolog are fixed within SIF. This implies that if a Zone Integration Server or Agent includes an XML prolog before a SIF message, it MUST take one of the following or equivalent forms (equivalent including case-insensitive character encoding names, XML's choice with regard to single or double quotes and optional spacing):

<?xml version="1.0"?>
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" standalone="yes"?>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

SIF uses a small subset of XPath 1.0 [XPATH] in its own path syntax for referencing elements/attributes. This is defined in SIF_Element Syntax. This document may often use the same notation in referring to nested elements and/or attributes (e.g. Name/FirstName, Name/@Type), though it may include an object as the root element whereas the SIF_Element syntax does not (e.g. StudentPersonal/Name/FirstName, StudentPersonal/@RefId).

SIFA hosts and provides XML Schemas [SCHEMA] for validating SIF messages, should Zone Integration Servers or Agents choose to perform message validation. These schemas leverage basic data types and structures as defined in that document. When these types and structures are referenced in this document they are prefixed with xs:.

Note that due to the ability of Zone Integration Servers and Agents to omit elements from data objects in the SIF Request/Response and SIF Event models, all elements defined as mandatory for SIF data objects in Infrastructure or Data Model and referenced common elements are defined as optional in the schema for validating any SIF_Message. SIFA hosts and provides alternate schemas that allow for validation of these data objects where mandatory elements cannot be omitted (e.g. in a Add event or in a SIF_Response where the SIF_Request did not specify a specific subset of elements to be returned from matching objects).

Notes on specific XML Schema types follow:

Namespaces allow XML elements and attributes to be organized into units that allow for the separation of a set of names from others, effectively allowing the integration of XML defined from various sources to be included in the same XML document without risk of name/definition collisions. SIF has since its initial release used the default namespace attribute xmlns [XMLNS] in the SIF_Message element. To a namespace-aware parser, the effective names of the elements in:

A namespace-unaware parser simply interprets elements by their local names, and SIF 1.x and SIF 2.x elements are considered equivalent. If the local name is prefixed, a namespace-unaware parser considers the prefix and colon part of the name. To a namespace-unaware parser, xml:lang is named just that. To a namespace-aware parser, this is effectively http://www.w3.org/XML/1998/namespace:lang (the xml prefix is reserved in XML 1.0 and is always bound to this namespace in [XMLNS]) with a local name of lang.

Given the timing of the first release of SIF and the release of Namespaces in XML [XMLNS] it was never mandated in SIF that Zone Integration Servers and Agents be namespace-aware. Given the number of Zone Integration Servers and Agents that may at this point be namespace-unaware, it is not yet mandated that these components be namespace-aware, but this requirement may arise in a future major release of this specification. To allow for namespace-unaware parsers to reliably process SIF-defined XML by local names only, SIF messages MUST define the namespace for the corresponding SIF version as the default namespace of SIF_Message as documented in SIF_Message.

Furthermore, given the gradual proliferation of XML defined in other namespaces appearing in SIF XML, the following prefix-to-namespace mappings MUST be used should elements from these namespaces occur in SIF messages, to allow namespace-unaware parsers to reliably interpret names in these namespaces by local name:

It is RECOMMENDED that other namespaces occuring in SIF messages (e.g. XML from outside SIF included in assessments, exchange of student records, etc.) have fixed prefix mappings, but it is not required. Affected elements MAY locally change the default namespace as desired, given that the default namespace for the SIF_Message as a whole remains the namespace for the corresponding SIF version.

When a fixed prefix is not defined for a given namespace, a namespace-unaware agent will be unable to reliably process these elements by name when prefixes vary, and must become namespace-aware to do so. XML not defined by SIF that in turn contains SIF-defined XML MAY reference SIF XML by its own prefix mapping rather than specifying the namespace of the corresponding SIF version as the default namespace using xmlns.

It is RECOMMENDED that as Zone Integration Servers and Agents are updated in their release schedules, they use namespace-aware parsers or parser options if they are not doing so already.

SIF leverages Universally Unique Identifiers (UUIDs), or Globally Unique Identifiers (GUIDs), as message and object identifiers, or primary keys, and occasionally for element identifiers internal to objects, per [RFC 4122]. Note that SIF defines its own textual representation for GUIDs, uppercase and un-hyphenated (e.g. F81D4FAE7DEC11D0A76500A0C91E6BF6 vs. f81d4fae-7dec-11d0-a765-00a0c91e6bf6). It should also be noted with SIF being a distributed system, to avoid the possibility of GUID collisions, especially in the SIF data model, systems generating GUIDs SHOULD use version 1 GUIDs which are unique in space as well as time when an IEEE 802 MAC address is available. Systems MAY use version 4 GUIDs which use a (pseudo-)random number-based algorithm if an IEEE 802 MAC address is unavailable or if the inclusion of that address in a GUID poses a compromising security risk.

SIF is a web service, "a software system designed to support interoperable machine-to-machine interaction over a network [WSARCH]." It is not a Web Service, as it lacks "an interface described in a machine-processable format (specifically WSDL) [WSARCH]." To meet this requirement and produce the Web Services Definition Language (WSDL) definition for SIF is a trivial exercise, creating a WSDL HTTP POST binding for the SIF_Message-in/SIF_Message-out exchange that describes the SIF HTTP(S) transport layer between Agents and ZIS, and between ZIS and Push-mode Agents. But the binding would be just that, a simple SIF_Message-in/SIF_Message-out exchange that doesn't capture the richness of the SIF infrastructure or necessarily provide the interoperability resulting from the precise definition of SIF HTTP(S). To do so and to meet the final requirement of a Web Service per [WSARCH], the use of SOAP messages, would require redefinition of much of SIF using SOAP messages. SIFA's Web Services Task Force has determined that this exercise has little value currently, given SIF's precisely defined transport layer and installed base. The task force has left it as a future task how to best leverage Web Services in the future of SIF's infrastructure, if at all. In the meantime, the task force has, however, decided to provide a Web Services interface that provides external systems access to the rich amount of data available in SIF Zones via its own specification [SIF Reporting WS]. Future opportunities to provide additional services may be identified.