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.

Monday, June 27, 2011

Documentation is for Everyone

Whenever someone is new to the Test Harness, I point out two important documents to read and understand.  The first is the FAQ the second is the HTTPS documentation.


Last week one of our members contacted me in the final stages of certifying one of their products.  Given only one class of tests remained, I figured we were way beyond anything the FAQ may cover.  Unfortunately, I was both right and wrong.  While the FAQ did not cover all the details involved in this situation, it proved to provide better background information than myself.  So if you will excuse me, I have some rereading to do.

John W. Lovell

Saturday, June 25, 2011

The limits of XML validation ... and how to extend them

Each XML element in the schema (XSD) for an XML document can be defined to be either mandatory or optional, depending upon the associated value of its “minoccurs” facet. If set to a zero (default) the element does not have to appear in the XML for the document to be valid. If set to a one, it must appear at least once or the XML document will be invalid. The problem is that this simplistic “all or nothing” metric results in almost all elements in a given document being declared as optional.
As a result, “valid” XML documents may be constructed which are missing key data elements necessary for providing an acceptable level of application interoperability.
What’s in a Name?
Consider “Middle Name”. Some students don’t have one, which means it must be an optional element of a Student object. Yet during testing, it is important to validate that an application can include a middle name in the “Create Event” for a Student, if the student does in fact have a middle name. Until now, there was no effective way to ensure that.
One obvious solution is to change the XML schema used during testing, to make Middle Name mandatory. So in the test cases at least, every student just happens to have a middle name, and if the application does not include it, it is a validation error.
Validation in the 4th Dimension
This rather straightforward solution comes up short in a few important cases. When many schools create a new section of an existing course, they may do so before assigning a room or a teacher to that section. This means the Create Event for a Section object cannot be required to contain the teacher or room even in a test situation, because that would violate the defined way the “Create Section” process evolves over time. Yet before any section can become “active” the Section object provider must issue one or more Change Events which contain these elements. But how can this time-based process requirement be verified?
The whole is greater than the sum of its parts
This issue was particularly challenging for the US Data Profile team, whose charter is to “define a higher level of SIF certification testing and to collaborate on a identifying the key set of K-12 objects and elements utilized by multiple states”. They had identified a set of currently optional SIF elements which needed to be provided by any application being certified to the US Data Profile. These included both middle name and the teacher of a section.
Their solution to ensuring whether a SIF application truly provides all “supported elements” rests on the following two techniques:
1. Every test case will include the supported element
2. The supported element will be made mandatory in the schema of the object response message
The first technique handles supported elements like “middle name”. The second allows supported elements to be provided in either the Create Event or in a later Change Event. The elements remain optional in these schemas and no validation error results if the element is missing from one or more of these Events. But at some point during the testing, a Request of the object will be issued and the Response must contain the element.
In this way, it can be verified that any application certified for the US Data Profile does in fact provide all Supported elements. This technique will be reused elsewhere in the SIF standard to tighten certification testing and increase the level of out of the box (OOB) interoperability between certified SIF applications.