Doing More With XML Schemas (part 3) - Of Fruits And Vegetables
(Page 3 of 6 )
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.
<?xml version="1.0" encoding="UTF-8"?>
<supermarket name="MyMart"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<aisle
name="fruits" number="1">
<item code="001" quantity="230" price="1.00"/>
<item
code="002" quantity="121" price="2.45"/>
<item code="003" quantity="60" price="3.15"/>
</aisle>
<aisle
name="vegetables" number="2">
<item code="004" quantity="500" price="1.15"/>
<item
code="005" quantity="600" price="0.75"/>
</aisle>
<items>
<item code="001">oranges</item>
<item
code="002">apples</item>
<item code="003">pineapples</item>
<item
code="004">onions</item>
<item code="005">potatoes</item>
</items>
</supermarket>
Only items that exist in the inventory "database" should appear within the various
<aisle>s of the supermarket.
In order to enforce this rule, I need to update my schema design again.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element
name="supermarket">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="aisle"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="item"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension
base="xsd:string">
<xsd:attribute name="code" type="xsd:positiveInteger"/>
<xsd:attribute
name="quantity" type="xsd:positiveInteger"/>
<xsd:attribute name="price"
type="xsd:decimal"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute
name="name"
type="xsd:string"/>
<xsd:attribute
name="number" type="xsd:positiveInteger"/>
</xsd:complexType>
<xsd:keyref
name="NoIllegalEntries" refer="itemKey">
<xsd:selector
xpath="item"/>
<xsd:field
xpath="@code"/>
</xsd:keyref>
</xsd:element>
<xsd:element name="items">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="item"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension
base="xsd:string">
<xsd:attribute name="code" type="xsd:positiveInteger"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute
name="name" type="xsd:string"/>
</xsd:complexType>
<xsd:key name="itemKey">
<xsd:selector xpath="items/item"/>
<xsd:field
xpath="@code"/>
</xsd:key>
</xsd:element>
</xsd:schema>
In case you missed it, here's the important bit:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- snip -->
<xsd:keyref
name="NoIllegalEntries" refer="itemKey">
<xsd:selector xpath="item"/>
<xsd:field
xpath="@code"/>
</xsd:keyref>
<xsd:key name="itemKey">
<xsd:selector
xpath="items/item"/>
<xsd:field xpath="@code"/>
</xsd:key>
<!-- snip
-->
</xsd:schema>
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,
<xsd:key name="itemKey">
<xsd:selector xpath="items/item"/>
<xsd:field
xpath="@code"/>
</xsd:key>
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.
<xsd:keyref name="NoIllegalEntries" refer="itemKey">
<xsd:selector xpath="item"/>
<xsd:field
xpath="@code"/>
</xsd:keyref>
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.
Next: Taking On The Fleet >>
More XML Articles
More By Harish Kamath, (c) Melonfire
/ 4 
