Enumeration extensions are difficult to deal with in any versioning scheme. Compare the difficulties in adding a new element to an object with adding a new allowed value to the end of an enumerated code list.
· If a legacy application receives a message with a new element (and XML verification is turned off) everything works. All previous elements the application depends upon are there, and the new element can be safely ignored, in accordance with the long established Best Practice for all SIF applications to just ignore any unknown elements in a received message.
· If the legacy application receives a message with code list element set to one of the new enumerated values, it can’t simply ignore it, because now the value of that element cannot be interpreted. The information is lost exactly as if the code list had been omitted.
There are several ways this can be dealt with:
1. Create a new code list element with the extended values and require applications conforming to the new release to fill in and send both.
This has the disadvantage that multiple elements in the message contain duplicate data.
2. Have the new application determine the version of its partner, and “translate” new enumerated values into the older set if it detects the partner is of an older version.
It is never a good strategy to lay “backward compatibility” constraints on every new application. In this case it wouldn’t work anyway, because a single SIF event gets routed to every subscriber, whether new or old version.
3. Have the ZIS do the translation whenever a new application is sending an event with a new code to a legacy subscribing application.
This can work, as the ZIS is the intermediary for every message in the SIF Zone, and already knows the versions of all connected applications. However it requires the ZIS to “break open the payload” of every message for this object type and search for this case, and make the conversion.
This violates the desired separation of the ZIS from the data model being supported in the Zone, and would likely impact overall Zone performance.
4. Make a careful examination of the list of the vendors of SIF-certified applications which from their CSQ matrices are known to subscribe to this object and utilize this enumerated element, and alert them to the coming change.
The goal here is to minimize the impact of what can be a breaking change introduced by the new release. It is obviously most effective in those cases where there has been minimal adoption and use of the affected enumerated element.
The end result is that depending upon the actual element involved, a different migration strategy could prove to be more optimal, and so it has not been possible to standardize on one approach. Each case then has to be considered on its merits.
They (enumerations) do not work well at all with objects that use foreign key definitions that allow a single field reference many different parent objects based on the value of the value of its sibling field.
Example: LibraryPatronStatus. You cannot add to an enumeration as it will BREAK backward compatibility. The Association needs to address this especially since they are adding more SIF objects that use a foreign key that is in two parts. One field to declare the parent and the other field to declare the foreign key value. The parent field is defined as a list.
Regarding the specific case mentioned (LibraryPatronStatus), there are two associated attributes:
· SIF_RefId (SIF-wide unique identification of a student or teacher)
· SIF_RefObject (The “type” of patron mapped to a SIF supported object – either StudentPersonal or StaffPersonal)
The problem comes up if the type alternatives were extended ... say to “ParentPersonal” (where a future version of the SIF standard allowed Parents to take out books). How would a legacy application respond to a Library Patron of an unknown RefObject type?
In this particular case, the migration plan might simply rely on the legacy application ignoring the entire LibraryPatronStatus object, because it could not understand (and then interpret) the parent class. So for this application, there would be no Parent Patrons of the school library.
This is in accordance with current Best Practices for SIF applications, and it seems the ony reasonable solution here. Other situations might require other migration plan alternatives.
What should be done is to clearly and concisely document the migration considerations for all “breaking” data model changes introduced in each release version, and this suggestion provides another justification for doing that. Current plans are to provide such “migration plan” collateral for all future releases.