XML Tutorial Schema – Complex Types

by Jaidev

Simply defined(!), Complex Types are elements that can contain sub-elements within or can have attributes.

In a more detailed hierarchy, the Complex Type is one of the following:

1. An empty element, or

2. A non-empty element

a. With text only, or

b. With elements only, or

c. With text and other elements (mixed content)

And each of the above categories can in turn be:

1. With attributes, or

2. Without attributes

Let us consider each of these in greater detail.

Empty Elements

An empty element has no content and may or may not have attributes. Consider the following example:

<xs:complexType name="emptyType">
 <xs:complexContent>
 <xs:extension base="xs:anyType">
 <xs:attribute name="anAttributeToTheEmptiness" type="xs:string"/>
 </xs:extension>
 </xs:complexContent>
</xs:complexType>

The key points to note are the xs:complexType tag which is standard for declaring complex types and the xs:complexContent tag which is used to create elements with no sub-elements. Also note that an attribute has been specified (called anAttributeToTheEmptiness) and the type extends “xs:anyType” since the tag of an empty element is inconsequential anyway.

An example based on the above complex type could look as follows:

Non Empty Elements

Non Empty elements as we have seen before, can be of three types – text only, elements only or mixed. Let us consider each now.

Text Only elements

These elements can only contain text and optionally may or may not have attributes. For instance, the type “bioData” below defines a Complex Type with text-only content:

<xs:complexType name="bioData">
 <xs:simpleContent>
 <xs:extension base="xs:string">
 <xs:attribute name="personName" type="xs:string"/>
 </xs:extension>
 </xs:simpleContent>
</xs:complexType>

And an example of an element based on the above complex type is:

<bioData personName=”Jaidev”>This is a short biodata of the person named Jaidev. He is the author of this XML Tutorial</bioData>

Notice the text inside the element “bioData” and the attribute “personName”. In passing, note also that one could use “restrictions” (learnt in the previous chapter) as well, within the element definition to further constrain the text content within the element.

“Elements Only” Elements(!)

There are four primary ways of having elements that contain only elements:

* Sequences

* All

* Choice

* Groups

Type of Containment	Description	Example
Sequence	* The sub-elements appear in a certain strict order. * Sequences can be nested or can contain choices or groups	<xs:element name="newspaper"> <xs:complexType> <xs:sequence> <xs:element name="name"/> <xs:element name="publisher"> <xs:complexType> <xs:sequence> <xs:element name="name"/> <xs:element name="address"/> <xs:element name="registerDate"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="city"/> <xs:element name="type"/> </xs:sequence> </xs:complexType> </xs:element>
Sequence	In the example to the right, the element “newspaper” is a sequence of the “name”, “publisher”, “city” and “type” that strictly need appear in that order. If the order were to be changed in the example element (say “type” comes before “city”, the element will be invalid.	An example: <newspaper> <name>The XML Daily</name> <publisher> <name>XML Master</name> <address>SGML Lane, Museum Sq</address> <registerDate>12 July 2001</registerDate> <city>XCitee</city> <type>Daily</type> </newspaper>
All	* The sub-elements can appear in any order. * The sub-elements can only be elements (not sequences, choices or groups)	<xs:element name="city"> <xs:complexType> <xs:all> <xs:element name="name"/> <xs:element name="state"/> <xs:element name="elevation"/> <xs:element name="mayor"/> </xs:all> </xs:complexType> </xs:element>
All	In the example to the right, note that the order of sub-elements as “elevation”, “state”, “mayor” and “name” is not the same order in which they were declared in the schema.	An example: <city> <elevation>540m</elevation> <state>Kansas</state> <mayor>Alexey</mayor> <name>See Sharp City</name> </city>
Choice	Gives a choice of one element (or group) or another.	<xs:element name="identifier"> <xs:complexType> <xs:choice> <xs:element name="name"/> <xs:element name="identityNo"/> <xs:element name="drivingLicense"> <xs:complexType> <xs:sequence> <xs:element name="licenseNo"/> <xs:element name="state"/> </xs:sequence> </xs:complexType> </xs:element> </xs:choice> </xs:complexType> </xs:element>
Choice	In the example to the right, notice that the identifier could be a “name” or an “identityNo” or even a “drivingLicense” (not shown)	Two alternative examples: <identifier> <name>Jaidev</name> </identifier> <identifier> <identityNo>A12345</identityNo> </identifier>
Group	This is a convenient way and common way of referencing a group of related elements at multiple locations within in the XML document.	<xs:group name="banking_history"> <xs:all> <xs:element name="main_bank"/> <xs:element name="years_there"> </xs:all> </xs:group> <xs:element name="individual"> <xs:complexType> <xs:sequence> <xs:element name="name"/> <xs:group ref="banking_history"/> </xs:sequence> </xs:complexType> </xs:element>
Group	In the example to the right, the “banking_history” maybe applicable to individuals, corporations or non-profit organizations. Thus a single group can be created and referenced in all the three definitions.	Two examples using the same reference: <individual> <name>Jon</name> <main_bank>POSB</main_bank> <years_there>4</years_there> </individual> <corporation> <orgID>BIZ567-2004-93</orgID> <main_bank>DBS Bank</main_bank> <years_there>6</years_there> </corporation>

Mixed Elements

These are elements that can contain text content as well as sub-elements within the element. And as usual, they may or may not have attributes.

Consider the following example:

<xs:complexType name="p" mixed="true">
 <xs:all>
 <xs:element name="b"/>
 <xs:element name="i"/>
 <xs:element name="u"/>
 </xs:all>
</xs:complexType>

An example of an html para with bold, italics and underline:

Fun Stuff with XML and XSL

which renders as

Fun Stuff with XML and XSL

Named and Anonymous Complex Types

Just as with Simple Types, elements can use named or unnamed (anonymous) complex types as well. The following boxes show both types of declaration for an element:

<xs:complexType name="weightType">
 <xs:sequence>
 <xs:element name="unit"/>
 <xs:element name="conversion"/>
 </xs:sequence>
</xs:complexType>

<xs:element name=”weight” type=”weightType”/>

<xs:element name="weight">
 <xs:complexType>
 <xs:sequence>
 <xs:element name="unit"/>
 <xs:element name="conversion"/>
 </xs:sequence>
 </xs:complexType>
</xs:element>

The box on the left declares a Complex Type named “weightType” which is then used to type the element “weight” (shown in blue boldface). In the box on the right however, the element “weight” (again shown in blue boldface) directly uses an anonymous Complex Type within itself. Note that the definitions of the Complex Types in both boxes are exactly the same. Only the method of referencing is different.

DTD’s and Schema’s Conclude

Over the last four chapters we have seen in fair depth how the syntax and structure of XML documents is specified. The earlier Document Type Definition and the later Schema have been the basis for many a XML document specification and now Schemas are gradually replacing DTDs are the default method.

With that, we have reached Camp II and the end of XML proper! Now we embark on a very interesting trail – that of transformation of XML. We will see some directly useful things that will explain why XML is surely taking centre stage when it comes to data interchange and display across sources, channels and endpoints.