Click here to Skip to main content
Click here to Skip to main content

XSD – Using the include element for schematic reuse

, 21 Jul 2005
Rate this:
Please Sign up or sign in to vote.
How to use the "include" element to introduce schematic reuse.

Introduction

XSD – or XML Schema Definition – defines an XML document outline in terms of constraints to content and structure. Such constraints are additional to those imposed by the basic definition of XML. XML documents can reference a specific schema and by doing so they become instances of that schematic type. Just like objects are instances of classes. An XSD is therefore an abstraction of a specific document type.

This article will look at schematic reuse, which is as advantageous as code reuse and for much of the same reasons. Schematic reuse is the ability to reuse a schema definition within another schema definition in such a way that the underlying (included) XSD can function as a type definition without relying on schemas that incorporate it or use it.

An XSD can be used and reused by multiple schemas, completing their type definition. Such sub structures can define reoccurring models that are generic in nature and highly distributed – like a data model that defines all aspects of an address.

Article scope

There are basically two ways of chaining schemas together. Both are defined by W3C:

  • Import – Import a schema from another namespace into the target schema.
  • Include – Include a schema that resides in the same namespace as the target schema.

This article will focus on the latter, the <include> element. The structure of the article will be in the form of an explained example where two schemas and a valid XML document instance are introduced. Some basic knowledge of XML and XSD is required to fully understand the examples and the explanations given.

Note: Using these two elements has a similar effect and the setup is somewhat identical but namespace qualification becomes an issue when using the <import> element.

The examples

Schema: Demo, (Demo.xsd)

<xs:schema xmlns="http://www.demo.com" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.demo.com" 
    elementFormDefault="qualified" version="1.0" id="demo"> 
    <xs:include schemaLocation="demo_include.xsd"/>
    <xs:element name="root" type="roottype"/>
    
    <xs:complexType name="roottype">
        <xs:sequence maxOccurs="unbounded">
            <xs:element name="record" type="recordtype"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="recordtype">
        <xs:annotation>
            <xs:documentation>this is the main element. 
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="id" type="xs:integer" nillable="false"/>
            <xs:element name="name" type="xs:string"/>
            <xs:element name="otherroot" type="otherroottype"/>
        </xs:sequence>
    </xs:complexType>
</xs:schema>

Schema: Demo include, (Demo include.xsd)

<xs:schema xmlns="http://www.demo.com" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.demo.com" 
    elementFormDefault="qualified" version="1.0" 
    id="demo_include"> 
    <xs:element name="otherroot" type="otherroottype"/>
    
    <xs:complexType name="otherroottype"> 
        <xs:sequence maxOccurs="unbounded">
            <xs:element name="otherrecord" 
                type="otherrecordtype"/>;
        </xs:sequence> 
    </xs:complexType>
    
    <xs:complexType name="otherrecordtype">
        <xs:annotation>
            <xs:documentation>
                this is the main element. 
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="id" 
                type="xs:integer" nillable="false"/>
            <xs:element name="name" type="xs:string"/>
        </xs:sequence>
    </xs:complexType> 
</xs:schema>

Xml Document (valid): demodata.xml

<?xml version="1.0" encoding="utf-8" ?>
<root xmlns="http://www.demo.com" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation=
          "http://www.demo.com:/projects/demodata.xsd">
    <record>
        <id>1</id>
        <name>John Doe</name>
        <otherroot>
            <otherrecord>
                <otherid>0</otherid>
                <othername>Jane Doe</othername>
            </otherrecord>
        </otherroot>
    </record>
</root>

Explanations

  • Each schema has a root element that implements a root type.
    • In both cases the root types incorporate a single element which points to a complex type that encapsulates the actual content.
  • The schemas are in the same namespace (http://www.demo.com).
    • This namespace is also set as the default namespace for both schemas.
    • Since the schemas share a namespace, each root element must be given a unique name (since they are "public"). Other elements or types within a schema can share names with elements or types found in other schemas in the same namespace (look at the "otherroot" element in the examples above). For the sake of clarity, I have tried to avoid this in the example schemas by supplying unique names to almost all the elements and types.
  • All elements are treated as "qualified" by default (both schemas).
  • The "demo_include" schema does not rely on the existence of the "demo" schema. It can be used separately to validate a sub-structure of the demodata.xml document shown above (where <otherroot> would be the root element of a document that could contain a number of <otherrecord> elements).
    • This is achieved by implementing a root element in each schema.
  • The "demo" schema includes the "demo_include" schema by using the <xs:include schemaLocation="demo_include.xsd"> statement. It then references the <otherroottype> from "demo_include" as the type for the <otherroot> element. This sets the structure described in the "demo_include" schema as a substructure in the "demo" schema.

A comment on Visual Studio .NET 2003

Please note that there is a bug in Visual Studio .NET 2003. The above-mentioned schemas are both valid. So is the XML document. If these schemas and the XML document are set up in a VS.NET project with the intention of using the "Validate Schema" and "Validate XML Data" functionality of the IDE, it will result in bogus error messages along the lines of:

  • "The active schema does not support the element Foo".
  • "The Foo element is not declared".

Other tools, such as XmlSpy, will not encounter these error messages when validating XML documents against schemas that use <import> or <include>.

Additional resources

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Jónas Antonsson
Web Developer
Iceland Iceland
Jónas B. Antonsson is a professional software developer. He's been in the business for eight years and has enjoyed some success.

Comments and Discussions

 
GeneralMy vote of 1 PinmemberMark102626-Nov-10 23:38 
Poorly edited. Bugs in all source code!
GeneralMy vote of 2 Pinmemberaniketathalye1-Jun-10 12:40 
GeneralBetter articles PinmemberJónas Antonsson5-Aug-05 8:48 
GeneralA copy/paste error PinmemberJónas Antonsson21-Jul-05 6:33 
GeneralRe: A copy/paste error PinmemberJónas Antonsson21-Jul-05 12:03 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.140721.1 | Last Updated 21 Jul 2005
Article Copyright 2005 by Jónas Antonsson
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid