Filing It All Away - XML

In the examples on the previous pages, I have shown you how to extend an existing datatype to create new sub-types. As the number of type definitions in your schema goes on increasing, it becomes hard to manage them all in a single file. At some point, you're going to want to organize and classify these type definitions for easy maintenance.

The XML Schema specification addresses this requirement via the <xsd:include> element, which allows you to call an external XML Schema document and reference the data within it in the current one.

In order to better understand this, let's split the schema on the previous page into two separate files. I'll begin with the root element and base type definitions, which I'll place in the file "base-defs.xsd":

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- 
base definitions -->
<xsd:complexType name="starWarsEntity">
<xsd:sequence>
<xsd:element 
name="name" type="xsd:string"/>
<xsd:element name="species" type="xsd:string"/>
<xsd:element 
name="language" type="xsd:string"/>
<xsd:element name="home" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element 
name="gallery">
<xsd:complexType>
<xsd:sequence>
<xsd:element 
name="character"
type="starWarsEntity" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

Next, I'll put all my derived types in the file "derived-defs.xsd".

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- 
include base types-->
<xsd:include schemaLocation="base-defs.xsd"></xsd:include>
<!-- 
derived types -->
<xsd:complexType name="Human">
<xsd:complexContent>
<xsd:extension 
base="starWarsEntity">
<xsd:sequence>
<xsd:element name="gender"
type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType 
name="Ewok">
<xsd:complexContent>
<xsd:extension base="starWarsEntity">
<xsd:sequence>
<xsd:element 
name="vehicle"
type="xsd:string"/>
<xsd:element name="society"
type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType 
name="Human">
<xsd:complexContent>
<xsd:extension base="starWarsEntity">
<xsd:sequence>
<xsd:element 
name="gender"
type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>

Obviously, I need to link the derived types to the base type - a task easily accomplished via the <xsd:include> element, which includes a "schemaLocation" attribute specifying the location of the schema to be sourced into the current file.

Once the schemas are linked together, all I need to do is specify the location of the last link in the chain - here, "derived-defs.xsd" - in my XML file,

<?xml version="1.0" encoding="UTF-8"?>
<gallery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="derived-defs.xsd">
...
</gallery>

and all the required definitions will be automatically included and used when required by the XML validator.

And that's about it for the moment. In this article, I took a step into the deeper waters of advanced schema design, demonstrating how to build complex datatypes by combining and grouping simpler ones. I also showed you how to apply some basic OOP concepts - extensibility and inheritance - to schema design by extending existing type definitions to create new ones, and demonstrated how to separate definitions into files for greater maintainability.

In the next article, I'll be continuing this discussion, demonstrating how to derive new types by restricting (rather than extending) existing ones, create abstract definitions and redefine existing types. Make sure you come back for that...and, until then, go practise!

Note: All examples in this article have been tested on Linux/i586. Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!

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

blog comments powered by Disqus