In Part 1 of this article we introduced SDO, looking at its origins and then reviewing some of its features through a scenario based on medical investigations. In Part 2 we'll go on to examine further features of SDO in such a way as to add property values to a data object beyond those explicitly defined by its type, the ability to record changes made to the data graph, a more elegant way to create types programmatically, and the ability to extend datatypes at runtime.

Our examples will depend on two XML Schema definition files that we'll reproduce here. The full details of the scenario they represent were presented in Part 1. These listings are available at http://gemsres.com/story/dec06/313547/source.html.

Part 1 of this article was published when version 2.01 of the SDO specification was current. Since then v2.1 has been released, however, in this article we'll continue to use version 2.01 for consistency.

Adding Open Content
The scenario begun in Part 1 now unfolds a little further. In particular, we'll examine the addition of values to a DataObject by virtue of the DataObject's type being open; that is to say, the property values in addition to those defined by its type. Joe Johnson has been found to have the rare condition, Panarr Syndrome. The designers of the test's data model have made use of the generic People model described in the first XML Schema from Part 1 and this design decision was only possible because the designer of the People model made the Person type open.

Note how in the schema for the medical test there are two global elements defined, one for the test itself and one for the medical condition. When the schema is read into the SDO runtime, these elements are translated into SDO global properties, scoped in the namespace URI of the schema. They're global properties, because they're not logically part of a type. It's this kind of global property that can be used to add information to an instance of an open type.

   Property conditionProperty = XSDHelper.INSTANCE.getGlobalProperty(
     "www.example.org/MedicalTest", "condition", true);
   DataObject condition = DataFactory.INSTANCE.create(
     "www.example.org/MedicalTest", "Condition");
   condition.setString("name", "Panarr Syndrome");
     List conditions = person1.getList(conditionProperty);
   conditions.add(condition);

In this code, SDO's XSDHelper has been used to look up the global property, and the DataFactory has been used to create a DataObject of the appropriate type. The interesting part of this code snippet is that when asked for the list of values associated with the "condition" property of the person DataObject, even though that property doesn't belong to the Person type and was never associated with the Person instance, the call to getList(conditionProperty) resulted in an empty list being created and returned. If the type of Person hadn't been open, this call would have resulted in an exception being thrown. Now we can simply add the condition to the list and any further serialization of this person instance will look like this:

   <person gender="male" id="1" name="Joe Johnson Snr.">
     <Test:condition name="Panarr Syndrome"/>
   </person>

It's worth noting that the SDO 2.1 specification adds to the SDO's capability for handling open content metadata and instance data.

Complex Graphs and Non-Containment References
In part 1 we examined one kind of relationship between data objects, that of containment. Every data object other than the root has exactly one parent data object that's its container. However, what if we want to express other relationships? In SDO these are represented by non-containment references.

We've already seen how SDO handles containment. We'll now explore adding complexity to the data graph by using non-containment links. Given the likelihood of members of Joe's family exhibiting Panarr Syndrome we'll add a list of Joe's relatives to the test set:

DataObject relatives = test.createDataObject("relatives");
DataObject person2 = relatives.createDataObject("person");
person2.setString("id", "2");
person2.setString("name", "Joe Johnson Jnr.");
DataObject relation = person1.createDataObject("relative");
relation.set("target", person2);
relation.set("relationship", "child");

This code snippet demonstrates the building of a complex graph using a non-containment link. We've created a new person in the test's set of relatives and made a link to that person from a new "Relative" property value for person1. So now our test looks like this:

<Test:Test xmlns:Test="www.example.org/MedicalTest"
   <referrals/>
   <patients>
     <person gender="male" id="1" name="Joe Johnson Snr.">
       <relative relationship="child" target="2"/>
       <Test:condition name="Panarr Syndrome"/>
     </person>
   </patients>
   <relatives>
     <person gender="male" id="2" name="Joe Johnson Jnr."/>
   </relatives>
</Test:Test>

Observe how the target attribute of the relative element has a value of "2," which is the id attribute value of the person "Joe Johnson Jnr" thus establishing the relationship from father to son. Looking back at the schema for Person, note how the use of the XML Schema "ID" attribute in the definition of the Person type and the "IDREF" attribute in the "Relative" type's target element lets us make this non-containment link. Having made the link, SDO needs a bit of help from the schema author to know what kind of value to expect the non-containment link to resolve to and so the "target" attribute is qualified by an sdoxml:propertyType attribute to indicate that any referenced objects will be the type Person.