SIF Association

This blog is run by the staff of the SIF (Schools/Systems Interoperability Framework) Association for the use of it's members and the general educational community.

It is specifically designed for those who are interested in understanding what SIF is about, where the standard is going and how Schools, Districts and State Educational Authorities will benefit.



Thursday, August 18, 2011

Enumerations are not compatible with the SIF * versioning implementation

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.

Tuesday, August 16, 2011

What’s up with Learning Resource and Associated Objects?

As more and more of you peruse the SIF Implementation Specification certain items are sure to strike you as odd.  Some come from the early days of our evolution, which everyone has simply accepted as the way it is.  Some more we have wanted to change for years but needed a major version in which to do the deed.   Others are simple inconsistencies that did not get caught during review.  Occasionally you will find one that stems from our versioning (or some other) policy.  Yet some are quite intentional, adopted for that special case where the norm simply did not fit the goals of the group.

The bizarre type-qualified Associated Objects of the Learning Resource object fall into this last group.  Normally the type of the object pointed to by RefId is included in its name (i.e. StudentPersonalRefId).  However, the Associated Objects in Learning Resource allow you to include a RefId for any object you like, as long as you also provide the type.  Why was this done?  Simply put, we wanted to be inclusive.  When you think about a learning resource it may need to point to anything from a book to a table saw, so we let you point to any object in the data model.  While there are some objects that should never be used here, they seems to be the exception rather than the rule.  You might even include people!  If a particular member of the staff is a critical component to the Learning Resource, go ahead, include a reference to a StaffPersonal object, why not, we will let you.

Of course the result of this linkage is a machine readable object, that more than likely needs to be presented nicely to a teacher or curriculum director.  Fortunately that is a feat that can be reasonably accomplished in a general way for the textual data of any single object.  While a vendor can still provide stunning visuals or deeper understanding for the objects they choose.

Enjoy the flexibility.

Monday, August 8, 2011

Where is the 2.4 and 2.5 Test Harness for an agent and ZIS?

Up and coming.  However, now is a good time to share some further details, so that those working on software of their own know what to expect.
Agent testing of the SIF Implementation Specification 2.4 (along with the Universal State Data Profile) is ready to be tried. We are excited to be in the midst of deploying it to our new staging server.  Once we have confirmed basic functionality, we intend to hold a beta for the entire membership.
The only reason we have been able to move forward on this agent testing is we have decided to not test Zone Services for the time being.  Since this is the most critical change in testing a 2.4 ZIS, we will not be scrutinizing them for 2.4 in the foreseeable future.  Although, a much more significant change which has already been adopted, is driving ZIS testing forward.
The SIF Implementation Specification 2.5 brings Web Services into an environment already racing to adopt Zone Services and Profiles.  Combined, these necessitate a more modular, flexible and extensible Test Harness.  One has been designed based on leveraging current assets; this design is undergoing late stage reviews while supporting code is being written and servers provisioned.
We indeed live in exciting times.

A Dialog on Deletion

Why does the SIF_Event/SIF_Action="Delete" require object payload?

The primary reason is consistency. By always contain an object instance with the RefId, we can always use one XPath (per ObjectName) to retrieve the RefId of the object we are working with.

Isn't all that is required is the object's primary key to indicate a delete?

Yes, that is the only part of the object required.  However, we need not include a lot of extra data when deleting or even changing an object.  While, an object contained in an add event or unfiltered response follows the data model schemas, a change event should only contain the information that has changed and a delete event only requires the RefId containing root.  For instance the following message has been validated (at : http://compliance.sifinfo.org/validate/).

<SIF_Message xmlns="http://www.sifinfo.org/infrastructure/2.x" Version="2.0r1">
  <SIF_Event>
    <SIF_Header>
      <SIF_MsgId>00000131AA65EE3A000A849450E61D66</SIF_MsgId>
      <SIF_Timestamp>2011-08-08T10:17:12</SIF_Timestamp>
      <SIF_Security>
        <SIF_SecureChannel>
          <SIF_AuthenticationLevel>0</SIF_AuthenticationLevel>
          <SIF_EncryptionLevel>0</SIF_EncryptionLevel>
        </SIF_SecureChannel>
      </SIF_Security>
      <SIF_SourceId>SIF_Empty_Query_Agent</SIF_SourceId>
      <SIF_Contexts>
        <SIF_Context>SIF_Default</SIF_Context>
      </SIF_Contexts>
    </SIF_Header>
    <SIF_ObjectData>
      <SIF_EventObject ObjectName="StudentPersonal" Action="Delete">
        <StudentPersonal xmlns="http://www.sifinfo.org/infrastructure/2.x" RefId="731A0F05E5C899B1E861322F5E6422B3" />
      </SIF_EventObject>
    </SIF_ObjectData>
  </SIF_Event>
</SIF_Message>

So if we were to use a special convention to specify the RefId when deleting an object, we would not save much in the way of network resources.  On the other hand, consistency brings simplicity in processing, which in turn saves resources there.


What should an agent do with the payload if received?

Retrieve the RefId and ignore the rest of the object to be deleted.  Of course you may be interested in related objects impacted by the delete, however those decisions should be based on the copy of the object in your database and not the one received.