Home arrow XML arrow Page 3 - Doing More With XML Schemas (part 3)

Of Fruits And Vegetables - XML

This article introduces you to the concept of uniqueness in the XML Schema world, showing you how to use built-in schema constructs to enforce uniqueness within your XML document instances.

  1. Doing More With XML Schemas (part 3)
  2. A Day At The Supermarket
  3. Of Fruits And Vegetables
  4. Taking On The Fleet
  5. Breaking The Mold
  6. Two For One
By: Harish Kamath, (c) Melonfire
Rating: starstarstarstarstar / 4
January 30, 2003

print this article


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.

>>> More XML Articles          >>> More By Harish Kamath, (c) Melonfire

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Google Docs and Xpath Data Functions
- Flex Array Collection Sort and Filtering
- The Flex Tree Control
- Flex List Controls
- Working with Flex and Datagrids
- How to Set Up Podcasting and Vodcasting
- Creating an RSS Reader Application
- Building an RSS File
- An Introduction to XUL Part 6
- An Introduction to XUL Part 5
- An Introduction to XUL Part 4
- An Introduction to XUL Part 3
- An Introduction to XUL Part 2
- An Introduction to XUL Part 1
- XML Matters: Practical XML Data Design and M...

Developer Shed Affiliates


Dev Shed Tutorial Topics: