Appendix E: Wildcard Version Support Implementation Notes

Agents that register the ability to receive SIF_Messages 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.

E.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"> <AlertMsg Type="Legal">A legal alert for Joe Student.</AlertMsg> <OtherId Type="06">P00001</OtherId> <Name Type="04"> <LastName>Student</LastName> <FirstName>Joe</FirstName> </Name> </StudentPersonal>
Example E.1-1: StudentPersonal from SIF Implementation Specification 1.1
<StudentPersonal RefId="D3E34B359D75101A8C3D00AA001A1652"> <AlertMsg Type="Legal">A legal alert for Joe Student.</AlertMsg> <LocalId>P00001</LocalId> <OtherId Type="06">P00001</OtherId> <Name Type="04"> <LastName>Student</LastName> <FirstName>Joe</FirstName> </Name> </StudentPersonal>
Example E.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.

E.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_Messages 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_Messages 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_Messages 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:<value of SIF_Message/@Version>/DTD/SIF_Message.dtd (for SIF 1.x—XSD/SIF_Message.xsd also available)<value of SIF_Message/@Version>/XSD/SIF_Message.xsd (for SIF 2.x)

E.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_Messages that may be introduced with the addition of optional infrastructure functionality into new minor releases of this specification, including new SIF_SystemControl messages.

Valid XHTML 1.0 Transitional