Note: An UI XML design tool like XMLSpy can be extremely helpful to better understand XML Schemas.
The purpose of an XML Schema is to define the legal building blocks for an XML document. It describes the metadata of its corresponding XML document. Using a database analogy, a table corresponds to XML Schema and the table's data corresponds to an XML document. XML Schemas allow you to:
Define elements that can appear in a document.
Define attributes that can appear in a document
Define which elements have child elements.
Define the order of child elements.
Define the number of child elements.
Define whether an element is empty or can include text.
Define data types for elements and attributes.
Define default and fixed values for elements and attributes.
One of the greatest strengths of XML Schemas is support for data types. With support for data types:
It is easier to describe permissible document content.
It is easier to validate the correctness of data.
It is easier to work with data from a database.
It is easier to define restrictions on data (known in XML Schema as facets).
It is easier to define data patterns
etc.
Another great strength of XML Schema is extensibility. Extensible XML Schemas allow you:
Create your own data types derived from standard types and hence, closely model real-life entities.
To reuse your schema in other schemas.
The following presents a very basic XML Schema followed by an XML document realization of that schema:
<?xml version="1.0" encoding="UTF-8"?>
<!-- The <schema> element is the root of every XML Schema document. The <schema>
element often includes attributes as shown below.
This schema is located at C:\Projects\XML\Projects\XMLSpyProject\Schema\BasicExample.xsd -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="www.diranieh.com/basic"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Book">
<xs:complexType>
<xs:sequence>
<
xs:element name="Author" type="xs:string"/>
<xs:element name="Title" type="xs:string"/>
<xs:element name="ISBN" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Notes:
<schema>
<schema>
is the root element of every XML schema.
xmlns:xs is a namespace:alias to indicate where elements and data types used in this schema come
from.
xmlns indicates the default namespace for this XML.
targetNamespace indicates that this schema describes data for any XML document whose namespace is identified by targetNamespace.
elementFromDefault and
attributeFromDefault are described in sections that
follow.
<element name="book">
These will be discussed further. For now, the <element> element is used to define what elements will appear in the XML file
The following presents an XML document that is based on the XML Schema given above:
<Book xmlns="www.diranieh.com/basic"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="www.diranieh.com/basic
C:\Projects\XML\Projects\XMLSpyProject\Schema\BasicExample.xsd">
<Author>Yazan</Author>
<Title>XML Schema</Title>
<ISBN>1234ABC</ISBN>
</Book>
Notes:
xmlns="www.diranieh.com/basic". This is the default namespace of this document. Corresponds to 'targetNamespace' in the schema.
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". This namespace allows you to use the schemaLocation attribute which takes two values: the namespace to use (www.diranieh.com/basic)and the path of the XML schema that defines the contents of that namespace. Note how schemaLocation attribute it is part of the namespace aliased by xsi.
The following defines a complex type that adheres to the structure described above. Note that elements and attributes defined within this complex type are considered local and as such can only be used within the context where they are defined. Therefore, local elements and attributes are unqualified by default. The following is a valid XML for an element whose type is <EmployeeType>:
<x:Employee Age="22" xmlns="http://www.diranieh.com">
<Name>Yazan</Name>
<Smoker>No</Smoker>
</x:Employee>
XML Schemas makes it possible to specify whether local elements and attributes should be qualified or unqualified using the elementFormDefault and attributeFormDefault attribute on the <schema> element. If these were set, then the above XML must be:
<x:Employee Age="22" xmlns="http://www.diranieh.com">
<x:Name>Yazan</x:Name>
<x:Smoker>No</x:Smoker>
</x:Employee>
A simple element does not define any structure, it just defines a value space. In other words, a simple element can contain only text and cannot contain any other elements or attributes. ?The 'only text' restriction is misleading as the text can be one of the types included in the XML schema definition (boolean, string, integer, etc.) or it can be a custom type that you define yourself. You can also add restrictions to the simple type to limit its content using facets (facets constraint the acceptable value of simple types).
For example, the following defines a new simple element named <Age> that is based on a simple element called <AgeType> whose base type is float and restricts its value to between 0.0 and 10.0. Also note that the element is assigned a default value if no value was assigned to this element when the XML document is created.
<!-- Example 1-->
<xs:simpleType name="AgeType">
<xs:restriction base="xs:float">
<xs:minInclusive value="0.0"/>
<xs:maxInclusive value="100.0"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="Age" type="AgeType" default="0"/>
<!-- Element Age is based on the AgeType simple type. Note the use of default
which is applied at the element and not simple-type level -->
<!-- XML -->
<Age>10</Age> <!-- OK -->
<Age>110</Age> <!-- Wrong. Outside restriction
-->
Another example:
<!-- Example 2-->
<xs:simpleType name="GenderType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="Male"/>
<xs:enumeration value="Female"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="Gender" type="GenderType"/>
<!-- Attribute Gender is based on the GenderType simple
type -->
<!-- XML -->
<Age Gender="M">20</Age>
In addition to restricting a base type, you can create simple types that use lists or unions of other simple types (use xs:list or xs:union instead of xs:restriction). The following creates a <xs:simpleType> named AgesType whose values are white space-delimited Age values:
<!-- Example 3 -->
<xs:simpleType name="AgesType">
<xs:list itemType="AgeType"/>
</xs:simpleType>
<xs:element name="Ages" type="AgesType"/>
<!-- XML -->
<Ages>10 30 45 67</Ages>
Simple elements (i.e., based on <xs:simpleType>) can only have text and cannot have attributes. If an element has attributes, the element must be based on a <xs:complexType>. The following example declares an attribute named ID that is based on an integer with a default value of -1. Attributes are optional by default. The use attribute specifies that this attribute is required:
<!-- Example 1 -->
<xs:attribute name="ID" type="xs:integer" default="-1" use="required">
<!-- XML -->
<Name ID="1">Yazan</Name> <!-- It is an
error to omit ID as it is required -->
Restrictions or facets are used to control or limit the acceptable values for elements and attributes. Restrictions are applied using the <xs:restriction> XSD element and can only appear under <xs:attribute> or <xs:simpleType>. There are many kinds of restrictions, but these can be divided into three categories:
Restrictions on values. For example, a value has to be within a certain range. Relevant schema attributes are minInclusive, maxInclusive, etc.
Restrictions on pattern of value. For example, a number which happens to represent price must have a specific format such a XX.XX.
Restrictions on set of values. In C# this would correspond to enums.
The following screen shot is taken from XMSPy which shows how restrictions (facets, patterns and enumerations) can be applied.
The following example illustrates:
<!-- Example 1 -- >
<xs:simpleType name="AgeType">
<xs:restriction base="xs:int">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="Age" type="AgeType"></xs:element>
<!-- XML -- >
<Age>60</Age> <-- OK -->
<Age>160</Age> <-- Incorrect. Outside range
defined by schema -->
The following example is the same as above except that the declaration of the <simpleType> is contained inside an element. This approach is less flexible than the previous one as no other element besides the containing element can be assigned to that type:
<!-- Example 2 -- >
<xs:element name="Age" >
<xs:simpleType name="AgeType">
< xs:restriction base="xs:int">
<xs:minInclusive
value="0"/>
<xs:maxInclusive
value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:element)
The following example shows how to declare a simple type that contains enumerators (the use of base keyword in explained further below. For now, it used to indicate the type of information that will appear in the enumerator. If the enumerator values were numbers, then the base would obviously be xs:integer)
<!-- Example 3 -- >
<xs:simpleType name="LanguageType">
<xs:restriction base="xs:string">
<xs:enumeration value="C#"/>
<xs:enumeration value="Java"/>
<xs:enumeration value="C++"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="Language" type="LanguageType"/>
The following example shows how to use a pattern to limit the actual characters that can be used for login in names. Again base="xs:string" indicates that the pattern deals with characters.
<!-- Example 4 -- >
<xs:simpleType name="LowerCaseType">
<xs:restriction base="xs:string">
<xs:pattern value="[a-z]"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="loginid" type="LowerCaseType" />
<!-- XML -- >
<loginid>yazan</loginid>
<!-- OK -- >
<loginid>Yazan</loginid>
<!-- Incorrect. Can only use lower case letters -- >
Another example of patterns:
<!-- Example 5 -- >
<xs:simpleType name="GenderType">
<xs:restriction base="xs:string">
<xs:pattern value="male|female"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="Gender" type="GenderType" />
There are many other restrictions that can be used. Please refer to XMLSpy and look at the Facets dialog box (shown above)
A simple element is based on <simpleType> and can only contains text (it cannot contain child elements or attributes). A complex element on the other hand is based on <complexType> and can contain child elements and attributes. In other words, while simple types define value spaces, complex types allows you to define structure There are four kinds of complex elements and an example of each is shown below:
<!-- Empty elements
(with/without attributes) -->
<product id="123"></product>
<!-- Elements that contain other elements (with/without
attributes) -->
<Laptop>
<name>Sony</name>
<price>999.99</price>
</Laptop>
<!-- Elements that contain text and attributes -->
<product id="123">Out of stock</product>
<!-- Elements that contain other elements and text
(with/without attributes) -->
<Car>
Under special offer
<name>BMW</name>
<price>19999.99</price>
</Car>
Complex elements are defined using <complexType> schema element. The overall structure is this: a complex type contains a 'compositor'. There are three compositors - <xs:sequence>, <xs:choice> and <xs:all>. Compositors in turn contain 'particles' which can be other compositors, elements, wildcards, and groups. Attributes are not considered particles because they do not repeat and are hence defined outside the particles. It is possible to indicate that a particle is optional by using minOccurs and maxOccurs schema attributes.
There are two ways to define complex elements: Define the complex type inside an <element> or define the complex type separately and then associate elements with that complex type. These two approaches are shown below:
<!-- Approach 1 -->
<xs:element name="Employee"
<!-- Complex type EmployeeType is
associated with element Employee. Complex type EmployeeType cannot be associated
with other elements -->
<xs:complexType name="EmployeeType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Smoker" type="xs:string" nillable="true"/>
</xs:sequence>
<xs:attribute name="Age" type="AgeType"/>
</xs:complexType>
</xs:element>
<!-- Approach 2 -->
<xs:complexType name="EmployeeType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Smoker" type="xs:string" nillable="true"/>
</xs:sequence>
<xs:attribute name="Age" type="AgeType"/>
</xs:complexType>
<!-- Associate an element with type EmployeeType. Note
that more than one element can be associated
with type EmployeeType-->
<xs:element name="Programmer" type="EmployeeType"/>
<xs:element name="TechnicalManager" type="EmployeeType"/>
<xs:element name="TestingManager" type="EmployeeType"/>
Note how the compositor is <xs:sequence> which means that the compositor's child elements must appear in the sequence specified:
<Employee Age="10">
<Name>Yazan</Name>
<Smoker>No</Smoker>
</Employee>
The best way to define complex elements is really to use XMLSpy as it will provide visual clues as to schema elements are available/enabled/disabled as the complex type is defined. Defining complex elements by hand is tedious and requires you to memorize what kind of child elements parents are allowed to have and so on. XMLSpy does all this by using visual clues to disable / enable allowed schema elements. The following sections discuss the four kinds of complex elements:
An empty complex element cannot have any content between its opening and closing tags, but it can contain attributes. Recall how an empty element looks like:
<!-- Empty elements
(with/without attributes) -->
<product id="123"></product>
Using XMLSpy we can visually design such an element:
Which generates the following definition:
<xs:complexType name="product">
<xs:attribute name="prodid"/>
</xs:complexType>
We can use XMPSpy to add restrictions to the prodid attribute as follows:
Which generates the following definition:
<!-- complexType product has an attribute named prodid
that is based on xs:positiveinteger. prodid is further limited to values between
0 and 9999 -->
<xs:complexType name="product">
<xs:attribute name="prodid">
<xs:simpleType>
<!-- The
minInclusive and maxInclusive must be children of an xs:restriction element. And
because the base of
xs:restriction is a simple type (positiveInteger), xs:restriction must appear
below an xs:simpleType element
-->
<xs:restriction
base="xs:positiveInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="9999"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
An elements only complex type refers to an an element that can only contain other elements. For example:
<!-- Elements that contain other elements (with/without
attributes) -->
<Laptop>
<name>Sony</name>
<price>999.99</price>
</Laptop>
The following shows how to create an element-only complex type with XMLSpy: First insert a complexType and then expand its definition:
One the xs:complexType has been opened, bring the context menu to add the xs:sequence compositor which is used to contain other elements that must appear in the same order in which they appear inside the xs:sequence compositor
This is how the xs:complexType appears after adding an xs:sequence compositor:
<xs:complexType name="laptopType">
<xs:sequence/>
</xs:complexType>
Two child elements are then added to the xs:sequence compositor. Each element is assigned a type of xs:string:
<xs:complexType name="laptopType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="price" type="xs:string"/>
</xs:sequence>
</xs:complexType>
We then create a laptop element whose type is laptopType. This means that all laptop elements must adhere to the structure of laptopType:
<xs:element name="laptop" type="laptopType" />
A text-only element is an element that contains text with/without attributes. For example:
<!-- Elements that contain text and attributes -->
<product id="123">Out of stock</product>
A complex type that does not contain child elements but does contain text is referred to as having a simple content. XML Schema use the xs:simpleContent tag to specify an element that does not contain child elements but instead contains simple types that can be extended or restricted. Note the following:
xs:simpleContent must have an xs:complexType parent.
xs:simpleContent can either have an xs:restriction or an xs:extension child element.
As seen before xs:restriction takes a type (say xs:integer) and is used to define constraints or limitations on that type. For example, values can only be between 1 and 10. On the other hand, xs:extension takes a type (such as xs:integer) and is used to expand or extend that type by adding specific attributes / attribute groups.
<xs:complexType name="shoesizeType">
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attribute
name="country" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="shoezie" type="shoesizeType" />
<shoezie counter="Italy">40</shoezie>
<-- Valid -- >
<shoezie counter="Italy">Not available</shoezie>
<-- Invalid. Content must be integer -- >
A mixed-content element is an element that can contain text and other child elements and attributes. For example:
<!-- Elements that contain other elements and text
(with/without attributes) -->
<Car>
Under special offer
<name>BMW</name>
<price>19999.99</price>
</Car>
To enable character data to appear between the child elements of a complex type, the xs:mixed attribute must be set to true. The above element can be declared as follows:
<xs:complexType name="carType" mixed="true">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="price" type="xs:float"/>
</xs:sequence>
</xs:complexType>
<xs:element name"car" type="carType />
Complex type indicators are used to control HOW elements are to be used in a document. There are seven types of indicators that fall under three categories:
Order indicators are used to control the order of element appearance. For example, the <xs:all> indicator indicates that all child elements must appear at least one but in any order. <xs:choice> indicates that only one child element out of many child elements can appear. Finally, <xs:sequence> that all child elements must appear in the given order.
Occurrence indicators are used to specify how often an element an element can occur. Occurrence indicators are minOccurs and maxOccurs.
Group indicators are used to define a logical grouping of elements. This logical grouping can then be referred to inside the schema instead of having to explicitly refer to all the members of that group. You can declare a group of elements with <xs:group> or a group of attributes with <xs:attributeGroup>.
The following examples illustrate:
<!-- Order indicator: all
-->
<xs:element name="person">
<xs:complexType>
<xs:all>
<xs:element name="firstname" type="xs:string"/>
<xs:element
name="lastname" type="xs:string"/>
<xs:element
name="Age" type="xs:integer"/>
</xs:all>
</xs:complexType>
</xs:element>
<!-- Order indicator:
choice -->
<xs:element name="person">
<xs:complexType>
<xs:choice>
<xs:element
name="firstname" type="xs:string"/>
<xs:element
name="lastname" type="xs:string"/>
<xs:element
name="Age" type="xs:integer"/>
</xs:choice>
</xs:complexType>
</xs:element>
<!-- Order indicator:
sequence -->
<xs:element name="person">
<xs:complexType>
<xs:sequence>
<xs:element
name="firstname" type="xs:string"/>
<xs:element
name="lastname" type="xs:string"/>
<xs:element
name="Age" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Occurrence
indicators: minOccurs and maxOccurs. Note GUI symbols for minOccurs = 0 (optional
element)
and maxOccurs = unlimited. -->
<xs:element name="person">
<xs:complexType>
<xs:sequence>
<xs:element
name="firstname" type="xs:string"/>
<xs:element
name="lastname" type="xs:string"/>
<xs:element
name="Age" type="xs:integer" minOccurs="0"/>
<xs:element
name="Children" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Group indicator:
group -->
<xs:group name="PersonInfo">
<xs:sequence>
<xs:element name="FirstName" type="xs:stirng"/>
<xs:element name="LastName" type="xs:string"/>
</xs:sequence>
</xs:group>
<xs:element name="person2">
<xs:complexType>
<xs:group ref="PersonInfo"/>
</xs:complexType>
</xs:element>
Note how element employee can use the PersonInfo group without having to re-declare FirstName and LastName elements:
<!-- Group indicator:
group and attributeGroup -->
<xs:group name="PersonInfo">
<xs:sequence>
<xs:element name="FirstName" type="xs:stirng"/>
<xs:element name="LastName" type="xs:string"/>
</xs:sequence>
</xs:group>
<xs:attributeGroup name="PersonInfoAtt">
<xs:attribute name="SystemID" type="xs:int" use="required"/>
<xs:attribute name="LoginID" type="xs:int" use="required"/>
</xs:attributeGroup>
<xs:element name="person2">
<xs:complexType>
<xs:group ref="PersonInfo"/>
<xs:attributeGroup ref="PersonInfoAtt"/>
</xs:complexType>
</xs:element>
Again, the attribute group PersonInfoAtt can be applied to any other element and that element will automatically get those attributes encapsulated within the attribute group.
Derivation is a very simple concept. Recall that <xs:simpleType> types derive from a base type and then specify whether this derivation is by xs:list or xs:union instead of xs:restriction. Same concept for <xs:complexType> types, except that derivation can be by xs:extension or xs:restriction. For all the above complex types note that there were no base type and hence no derivation. Note the following example:
<!-- The structure
below the complex type 'DerivationType_Simple was added automatically by the
IDE when I specified a base that was a simple type -->
<xs:complexType name="DerivationType_Simple">
<xs:simpleContent>
<xs:extension base="xs:string"/>
</xs:simpleContent>
</xs:complexType>
<!-- The elements below <xs:complexType name="DerivationType"> below was added
automatically by the IDE when I specified a base that was a complex type -->
<xs:complexType name="DerivationType_Complex">
<xs:complexContent>
<xs:extension base="EmployeeType">
<xs:sequence>
<xs:element name="element1" type="xs:string"/>
</xs:sequence>
<xs:attribute name="attribute1" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The <xs:any> schema element allows you to extend the XML document with elements not defined by the schema, whereas <xs:anyAttribute> schema element allows you to extend the XML document with attributes not defined by the schema. The following example illustrates:
<xs:complexType name="documentType">
<xs:sequence>
<xs:element name="Title"/>
<xs:element name="Category"/>
<xs:any minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<element name="document" type="documentType" />
For example, the following XML is valid event through the corresponding schema type does not explicitly declare the id attribute id the ChapterTittle element.
<document id="123ABC">
<Title>XML Schema</Title>
<Category>Programming</Category>
<ChapterTitle>Introduction</ChapterTitle>
<ChapterTitle>Basic elements</ChapterTitle>
</document>
XML element substitution allows you to specify that element X can be used instead of element Y. Let's say that you need to populate two database, SQL Server and Oracle using an XML file that specifies table names and data. We would like the ability to choose table names for the appropriate database type. To solve this problem, we define a substitution group in the XML Schema which is used to identify the target element that can be substituted. For example, consider the following schema:
<xs:complexType name="tableCustomer">
<xs:sequence>
<xs:element name="FistName"/>
<xs:element name="LastName"/>
<xs:element name="CustomerID"/>
<xs:element name="DOB"/>
</xs:sequence>
</xs:complexType>
<xs:element name="sqlserverCustomer" type="tableCustomer"/>
<xs:element name="oracleCustomer" substitutionGroup="sqlserverCustomer"/>
Based on the above, both of the following XML fragments are valid:
<sqlserverCustomer>
<FistName/>
<LastName/>
<CustomerID/>
<DOB/>
</sqlserverCustomer>
<oracleCustomer>
<FistName/>
<LastName/>
<CustomerID/>
<DOB/>
</oracleCustomer>
To prevent other elements from being substituted for a specific element, we use the block attribute:
<xs:element name="sqlserverCustomer" type="tableCustomer"
block="substitution"/>
<xs:element name="oracleCustomer" substitutionGroup="sqlserverCustomer"/>
This means that is is no longer possible to substitute oracleCustomer element for sqlserverCustomer elements.
Like any programming language, XSD has many data types. Of special importance string and date/time data types.
String date types can contain characters, numbers, line feeds, carriage returns and tabs. For example, the following is valid XML:
<xs:element name="customer" type="xs:string" />
<!-- The XML processor
will not modify the value when you use the xs:string type -->
<customer> some customer name </customer>
<!-- spaces are due to tabs -->
XSD also offers xs:normalizedString data type which is the same as xs:string except that the XML processor will remove line feeds, carriage returns and tabs.
<xs:element name="customer" type="xs:normalizedString" />
<!-- The XML processor
will modify the value when you use the xs:normalizedString type by replacing
tabs with spaces-->
<customer> some customer name </customer>
<!-- tabs are now replaced with spaces -->
XSD also offers xs:token data type which is the same as xs:string except that the XML processor will remove line feeds, carriage returns, tabs, leading and trailing spaces and multiple spaces.
Date values in XML are always specified with the YYYY-MM-DD format using the xs:date element. For example:
<element name="DOB" type="xs:date" />
<DOB>2000-12-31</DOB>
To specify a time zone, you can enter a date in UTC time by adding a "Z" behind the date or you can specify an offset from UTC time by adding a positive or negative time:
<Start>2000-12-31Z</Start>
<Start>2000-12-31+08:00</Start>
Time values in XML are always specified with the hh:mm:ss format using the xs:time element. For example:
<element name="Takeoff" type="xs:time" />
<Takeoff>18:20:00</Takeoff>
To specify a time zone, you can enter a date in UTC time by adding a "Z" behind the date or you can specify an offset from UTC time by adding a positive or negative time:
<Takeoff>16:30:00Z</Takeoff>
<Takeoff>09:30:10+08:00</Takeoff>
DateTime values in XML are always specified with the YYYY-MM-DDThh:mm:ss format using the xs:time element. For example:
<element name="Takeoff" type="xs:dateTime" />
<Takeoff>2000-10-20T18:20:00</Takeoff>
The following examples illustrate other features of XML Schema that can be used when dealing with dates/times:
<!-- To specify a time zone, you can enter a date in UTC time by adding
a "Z" behind the date
or you can specify an offset from UTC time by adding a positive or negative time
-->
<Takeoff1>2000-10-20T18:20:00Z</Takeoff1>
<Takeoff2>2000-10-20T18:20:00+08:00</Takeoff1>
<!-- Time intervals can be
specified using the form PnYnMnDTnHnMnS
where n indicates the count
You can add a leading negative sign to indicate a negative period
-->
<Period1>P5Y</Period1>
<!-- 5 years - >
<Period2>P2M10D</Period2> <!-- 2
months 10 days - >
<Period3>10DT15H</Period3> <!-- 10 days
15 hours - >
<Period>-2Y10DT04H</Period> <!-- Minus 2 years
10 days 4 hours - >
<!-- The
<xs:decimal> type is used to specify a numeric
value. It is the base class of most
numeric types including <xs:integer>,
<xs:short>, <xs:unsignedByte>,
etc -->
<xs:element name="ProductID" type="xs:decimal" />
<ProductID>1234</ProductID>
<!-- The <xs:boolean> type
can take true, false, 0 or 1-- >
<xs:attribute name="enabled" type="xs:boolean" />
<Login enabled="1">yazan</Login>
<!-- The anyURI data type
is used to specify a URI -->
<xs:element name="Site" type="xs:anyURI" />
<Site>www.diranieh.com</Site>
<!-- The following references a global element named Age. Note the use of the
ref keyword-->
<xs:complexType name="EmployerType">
<xs:sequence>
<xs:element ref="Age"/>
</xs:sequence>
</xs:complexType>
<!-- Here the compositor is all. It has some restrictions in that it only allows
element particles.-->
<xs:complexType name="complexType1">
<xs:all>
<xs:element name="element1" type="xs:string"/>
</xs:all>
<xs:attribute name="attribute1" type="xs:string"/>
<xs:anyAttribute/>
</xs:complexType>