Appendix E: Wildcard Version Support Implementation Notes

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.

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:

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)

E.3 SIF_Message Handling