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

Filing It All Away - XML

Get into the more advanced aspects of XML Schema design with a discussion of simple and complex datatypes, and learn to apply the basic OOP concepts of extensibility and inheritance to your schemas.

  1. Doing More With XML Schemas (part 1)
  2. A Complex Web
  3. Nesting Season
  4. Extending Yourself
  5. Filing It All Away
By: Harish Kamath, (c) Melonfire
Rating: starstarstarstarstar / 6
January 07, 2003

print this article


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
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: