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":
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,
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!