Next, how about introducing a referential integrity constraint similar to the one in the example above? Let's say we have a master list of available droid types, and only those droid types may be requisitioned for the various ships in the fleet. Here's my new XML document:
There are two significant changes in this version of the XML document. First,
I have introduced a listing of droids which will act as a master list for all the droids on the ships of the fleet. To make things easier, I have further classified the droids on each ship into sections like administration, communication and repairs, based on their advertised functionality.
Now, all I need to do is update the schema to reflect this referential integrity constraint, in a manner similar to that in the previous example:
As I have three functional groups for droids on each ship, the key reference
needs to be repeated thrice, one for each group (you could probably do this in a more efficient manner if you have a large number of groups - I leave that to you as an exercise, preferring this slightly clunkier option for illustrative purposes). The "refer" attribute of each <xsd:keyref> element links this constraint to the droid master list via the unique label "droidNameKey".
And that's it! You now have two constraints in a single schema definition, one ensuring that ship names are unique, and the other ensuring that only valid droids appear in each ship. Try it out and see for yourself!