Doing More With XML Schemas (part 1) - Filing It All Away (
Page 5 of 5 )
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!
