A Day At The Supermarket - XML

What's a supermarket got to with an XML schema, you ask wonderingly? Quite a lot, actually. You see, all supermarkets consist of aisles, with products placed neatly in each aisle for customers and employees alike. In an XML document, this design would be represented as follows:

<?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>
</supermarket>

As you can see, I have a list of <aisle> elements, which in turn enclose multiple <item> elements. Each <aisle> is associated with a "name" that represents the category of items in the aisle, and a "number", which is used for easy reference. Each <item> is associated with a "quantity" and a "price".

Writing an XML schema to validate the XML document instance above is child's play, especially considering the amount of practice I've had over the last couple of weeks.

<?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:element>
</xsd:sequence>
<xsd:attribute 
name="name" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>

Now, let's suppose that, one fine day, the store manager decides to add a few items to aisle 1. In the XML universe, he has two options available to him: he could add it to the existing <item> list for the appropriate aisle, or he could add another <aisle> element to the bottom of the document instance, reference it with the same aisle number, and attach the new items there.

<?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>
<aisle name="fruits" 
number="1">
<item code="014" quantity="200" price="1.35"/>
<item code="015" 
quantity="300" price="0.55"/>
</aisle>
</supermarket>

With option two, the XML document instance doesn't look as clean as it did initially. Proceeding along this path, it would soon have a number of different entries for the same <aisle> at different locations in the document tree. Obviously, this is a maintenance nightmare.

You can prevent this from happening via the very cool <xsd:unique> element - as in the revised schema below:

<?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:element>
</xsd:sequence>
<xsd:attribute 
name="name" type="xsd:string"/>
</xsd:complexType>
<xsd:unique name="NoRepeatAisle">
<xsd:selector 
xpath="aisle"/>
<xsd:field xpath="@number"/>
</xsd:unique>
</xsd:element>
</xsd:schema>

I'm not going to get into a long-winded explanation of the entire schema above. Instead, let me focus on the interesting part:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- snip -->
<xsd:unique 
name="NoRepeatAisle">
<xsd:selector xpath="aisle"/>
<xsd:field xpath="@number"/>
</xsd:unique>
<!-- 
snip -->
</xsd:schema>

The <xsd:unique> element is what gets the ball rolling - it is used to impose uniqueness constraints on an XML document instance. You can assign it a name - I've called mine "NoRepeatAisle" - to makes its function clearer.

The <xsd:unique> element encloses <xsd:selector> and <xsd:field> elements, which help to identify the unique components of the document. The "xpath" attribute of the <xsd:selector> element contains an XPath expression that helps to limit the scope within which the uniqueness constraint will be applied. In my case, this is restricted to all the <aisle> elements that are the children of the <supermarket> element only; if there exist any other <aisle> elements in the hierarchy, this constraint is not valid.

The second element component of the uniqueness constraint is the <xsd:field> element, which specifies which attribute values should be unique - in the example above, this is the value of the "number" attribute.

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

blog comments powered by Disqus