Agents that register the ability to receive SIF_Message
s defined by any number of
different SIF Implementation Specification versions by using
version wildcards in SIF_Register/SIF_Version
and SIF_Request/SIF_Version
may receive messages defined by specification versions that did not
exist at the time of agent implementation. This support can maximize agent communication in zones supporting multiple
SIF versions; agent developers that design this support should be aware of the following implementation notes. These
notes focus on wildcard support for releases within a given major release lifecycle and do not address agents
that register support for *
, indicating the ability to receive ANY version
SIF_Message
. These messages can be very different structurally across major version boundaries and an
agent may require more sophisticated capabilities to successfully process any SIF_Message
, regardless of
the SIF version that defines it.
The message handling protocols documented in this specification are written from the perspective of having a well-formed
and—optionally—valid XML document and the ability to randomly access element and attribute values within the document in performing
the message handling steps as documented. While some agent implementations have this ability, there do exist agent
implementations that may process SIF XML using a streaming interface (e.g. SAX), processing an XML document node by node,
to perform equivalent functionality. When these agents declare the ability to receive a SIF_Message
defined by any minor release within a major release lifecycle, they cannot assume in processing a message that
one element follows another without any intervening elements, as new minor releases of this specification can introduce
optional elements into the SIF Data Model. An agent written at the time of SIF Implementation Specification 1.1
to support 1.*
and to expect
OtherId
to follow AlertMsg
might encounter difficulties with processing a 1.5r1
StudentPersonal
if it were not designed to ignore new intervening 1.5r1 elements
before OtherId
unknown at the time of implementation, including LocalId
, as shown here, not to mention StatePrId
and ElectronicId
, which were also both introduced
in SIF Implementation Specification 1.5r1.
Agents that parse XML on a node-by-node basis and that wish to support wildcard versions must be able to read and skip XML elements not of interest until an expected element of interest is reached.
Though minor releases within a major version lifecycle of this specification are designed to be
supersets of previous minor releases, agents supporting wildcard versions and performing XML validation
should take into consideration that messages from a higher
minor version in a major version lifecycle will not validate against schemas designed for a lower version, given the potential introduction of new objects,
and new optional elements into existing data objects. Agents that do perform XML validation should skip
validation of received SIF_Message
s that are defined by a higher version, unless they have dynamic
Internet access to hosted schemas where SIF_Message/@Version
can be used to access schemas
for new specification releases. These agents can, of course, still establish that received SIF_Message
XML is well-formed and process that XML to access elements/attributes of interest to the agent implementation.
While SIF_Message
s defined by lower minor versions in a major version lifecyle may validate against
a higher-version schema in that lifecycle, it is recommended also that higher-version agents skip XML validation
of lower-version SIF_Message
s unless they have local access to schemas corresponding to the version in
question, in which case the appropriate schema should be used for validation, or unless they have dynamic Internet
access to hosted schemas where SIF_Message/@Version
can be used to access schemas for other specification
releases. This recommendation is made particularly because external code sets may be brought up to date with external
sources with each release of this specification and a previously valid code set value may become invalid in
a new specification.
Note that schemas hosted by the SIF Association are available at well-known URLs and can be used to dynamically access schemas for older/newer
specification versions using SIF_Message/@Version
, should agents with Internet access require them for
XML validation:
http://www.sifinfo.org/infrastructure/<value of SIF_Message/@Version>/DTD/SIF_Message.dtd
(for SIF 1.x—XSD/SIF_Message.xsd
also available)http://specification.sifinfo.org/Implementation/<value of SIF_Message/@Version>/XSD/SIF_Message.xsd
(for SIF 2.x)
While this is defined in the SIF_Message Agent Message Handling Protocol, it bears
repeating in this section that agents receiving an unexpected message from the ZIS respond according to protocol,
acknowledging receipt of the message with a SIF_Ack
including the SIF_Error
element with a SIF_Category
of 12
(Generic Message Handling) and a SIF_Code
of
2
(message not supported). This
allows an agent with wildcard version support to successfully ignore SIF_Message
s that may be introduced
with the addition of optional infrastructure functionality into new minor releases of this specification,
including new SIF_SystemControl
messages.