# Appendix D: Wildcard Version Support Implementation Notes

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.

## D.1 XML Parsing

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.

<StudentPersonal RefId="D3E34B359D75101A8C3D00AA001A1652"> <AlertMessages> <AlertMessage Type="Legal">This is the Legal Alert for Joe Student</AlertMessage> </AlertMessages> <OtherIdList> <OtherId Type="0339">206654</OtherId> </OtherIdList> <Name Type="04"> <LastName>Student</LastName> <FirstName>Joe</FirstName> </Name> </StudentPersonal>
Example D.1-1: StudentPersonal from SIF Implementation Specification 1.1
<StudentPersonal RefId="D3E34B359D75101A8C3D00AA001A1652"> <AlertMessages> <AlertMessage Type="Legal">Legal Alert for Joe Student</AlertMessage> </AlertMessages> <LocalId>P00001</LocalId> <OtherIdList> <OtherId Type="0339">206654</OtherId> </OtherIdList> <Name Type="04"> <LastName>Student</LastName> <FirstName>Joe</FirstName> </Name> </StudentPersonal>
Example D.1-2: StudentPersonal from 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.

## D.2 XML Validation

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)

## D.3 SIF_Message Handling

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.