The schema design on the previous page ensures that a truant store manager cannot damage the integrity of my XML document instance by throwing up new aisles wherever (s)he likes. Now, let's take it one step further and add another integrity check, this one to ensure that the <item>s in each aisle actually exist in the store's inventory system.
Here's the updated document instance - note that, this time around, I've added an extra <items> block that serves as the inventory, matching item codes with a human-readable description of each item.
In order to enforce the "only-add-those-items-to-aisles-that-exist-in-inventory"
rule, I need to import two new concepts into my schema, concepts that may already be familiar to you from your work on relational databases: keys and relationships.
In the database world, a primary key uniquely identifies every record in a table - it might be a single field, or a combination of fields, but it serves as a unique fingerprint to identify any record in a table. It also serves as an important component of the relational database model - relations between different tables are created on the basis of primary keys.
Based on this knowledge, it's pretty obvious what the primary key is in the scenario above - it's the "code" attribute of each <item>. Or, to put it in schema lingo,
Key definition takes place via the <xsd:key> element, which identifies the
key by a unique name. The <xsd:selector> and <xsd:field> elements are then used, in conjunction with regular XPath expressions, to drill down to the element/attribute combination representing the primary key.
Once the key is defined, the next step is to define a relationship around which it pivots. In the scenario above, it is fairly clear that the key reference has to be maintained between the <item> under the <items> element (the inventory master list) and the <item> under the <aisle> element (the inventory itself).
With this in mind, let's add a condition to the schema definition with the <xsd:keyref> element.
The <xsd:keyref> element is used to indicate a reference to a key defined
elsewhere in the schema. I have given the reference an appropriate name - "NoIllegalEntries" - which is displayed to the XML document author by the validator in case a violation of the reference takes place. The "refer" attribute of the <xsd:keyref> element links this reference to the primary key defined previously, via the unique key name "itemKey".
At this point, an integrity check has been added to the schema to ensure that only valid <items> from the inventory appear in the <aisle>s. You can verify this by adding an item to the aisles with a product code not listed in the inventory - your XML validator should barf and throw up lots of ugly errors.