XML Schema Definition (XSD): How XML Documents Get Their Rules
Learn how XML Schema Definition (XSD) defines the structure of XML documents using elements, attributes, data types, namespaces, occurrence constraints, value restrictions, and schema validation.
Two systems exchange customer information using XML. The first sends this:
<customer>
<name>Julia Norton</name>
<age>34</age>
</customer>
The second expects this:
<customer>
<fullName>Julia Norton</fullName>
<age>34</age>
<email>julia@example.com</email>
</customer>
Both documents can be perfectly readable XML, yet the systems still disagree about what a customer is supposed to look like. One expects name, the other expects fullName. One requires an email address, while the other doesn’t send one at all.
This is where XML Schema Definition, usually called XSD, becomes useful. XSD is a schema language for describing the permitted structure and content of XML documents. Instead of every application making its own assumptions, a schema can define which elements are allowed, where they appear, what data they contain, which attributes are available, and how often particular elements can occur.
In other words, XML carries the data. XSD describes the rules that data is expected to follow.
XML Gives You Structure, but Not Your Structure
XML already has rules. Elements need to be nested correctly, opening and closing tags must match, attribute syntax must be valid, and the document needs a single root element.
This XML is structurally well formed:
<customer>
<name>Julia Norton</name>
<age>thirty-four</age>
</customer>
The XML parser has no reason to object to thirty-four. As far as XML itself is concerned, that is ordinary text.
But what if the validation requires age to contain an integer. The XML syntax alone cannot express that business rule.
An XSD can:
<xs:element name="age" type="xs:integer"/>
Now the schema says something more specific than “an age element may exist.” It says the value of that element must conform to an integer data type.
This distinction between XML syntax and XML schema rules is fundamental to understanding XSD.
XSD Is an XML Schema Language
XSD is a W3C XML schema language used to define the structure and data constraints of XML documents. An XSD document is itself written using XML syntax, which means its rules are represented using elements and attributes.
A very small schema might look like this:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="message" type="xs:string"/>
</xs:schema>
This schema declares that an XML document can contain a message element whose value is a string.
A matching XML document could be:
<message>Hello</message>
That example is deliberately simple, but larger schemas use the same basic idea to describe deeply nested documents containing hundreds of different elements and attributes.
Element Declarations Define What Can Appear
XML documents are built around elements, so element declarations are a major part of XSD.
An element can be declared like this:
<xs:element name="firstName" type="xs:string"/>
This establishes two useful pieces of information:
Element name → firstName
Data type → string
Other elements can use different types:
<xs:element name="age" type="xs:integer"/>
<xs:element name="active" type="xs:boolean"/>
<xs:element name="created" type="xs:date"/>
A schema can therefore distinguish between values that might all look like text in the XML file but represent very different kinds of information to the application.
That becomes especially valuable when XML is exchanged between systems. A field called created does not merely need to exist; both sides can agree that it is expected to contain a date.
XSD Has Built-In Data Types
XSD provides a substantial collection of data types rather than treating every value as arbitrary text.
Common examples include:
xs:string
xs:boolean
xs:decimal
xs:integer
xs:date
xs:dateTime
A schema might contain:
<xs:element name="productName" type="xs:string"/>
<xs:element name="price" type="xs:decimal"/>
<xs:element name="quantity" type="xs:integer"/>
<xs:element name="available" type="xs:boolean"/>
A corresponding XML document could then contain:
<productName>Mechanical Keyboard</productName>
<price>129.99</price>
<quantity>4</quantity>
<available>true</available>
Data types allow validation to catch problems earlier. If quantity suddenly contains four, a schema-aware validator can reject the document before an application attempts to treat that value as a number.
Simple Types Describe Values Without Child Elements
XSD divides types broadly into simple types and complex types.
A simple type represents a value that does not contain child elements. A straightforward example is:
<xs:element name="username" type="xs:string"/>
The XML might be:
<username>julia</username>
Simple types become more interesting when restrictions are added. Suppose usernames must contain between 3 and 20 characters:
<xs:simpleType name="UsernameType">
<xs:restriction base="xs:string">
<xs:minLength value="3"/>
<xs:maxLength value="20"/>
</xs:restriction>
</xs:simpleType>
An element can then use that custom type:
<xs:element name="username" type="UsernameType"/>
The schema is no longer simply describing the general kind of data. It is narrowing the values that are acceptable for this particular document format.
Complex Types Describe Structured Content
A complex type is used when an element contains child elements, attributes, or more complicated structure.
Consider this XML:
<customer id="1042">
<name>Julia Norton</name>
<email>julia@example.com</email>
</customer>
The customer element contains other elements and an attribute, so its XSD might look like:
<xs:element name="customer">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
</xs:sequence>
<xs:attribute name="id" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
The schema now describes several aspects of the document at once: customer contains name and email, those elements appear in a defined sequence, and customer also requires an integer id attribute.
This is where XSD begins to look less like a list of fields and more like a description of an entire document structure.
Attributes Can Have Rules Too
XML attributes carry information inside an element’s opening tag:
<customer id="1042" status="active">
XSD can define these attributes just as it defines elements:
<xs:attribute name="id" type="xs:integer" use="required"/>
<xs:attribute name="status" type="xs:string"/>
The use="required" declaration means the first attribute must be present.
Without it:
<customer>
the document would fail validation against that part of the schema.
Attributes can also use custom simple types and restrictions, allowing schemas to control their permitted values rather than accepting arbitrary strings.
Sequence Defines Order and Hierarchy
XML is hierarchical. Elements contain other elements, which can contain elements of their own.
XSD needs a way to describe those relationships.
One common mechanism is xs:sequence:
<xs:sequence>
<xs:element name="firstName" type="xs:string"/>
<xs:element name="lastName" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
</xs:sequence>
This describes an expected order:
customer
│
├── firstName
├── lastName
└── email
An XML document following that structure might contain:
<customer>
<firstName>Julia</firstName>
<lastName>Norton</lastName>
<email>julia@example.com</email>
</customer>
Hierarchy becomes increasingly important in larger XML formats because the same element name can have different meaning depending on where it appears in the document.
Occurrence Constraints Control How Often Elements Appear
Sometimes an element is required exactly once. Other times it is optional or can appear repeatedly.
XSD represents these rules using minOccurs and maxOccurs.
For example:
<xs:element
name="phoneNumber"
type="xs:string"
minOccurs="0"
maxOccurs="unbounded"/>
This means a phone number is optional and can occur multiple times.
The basic pattern is:
minOccurs="0" maxOccurs="1" → optional
minOccurs="1" maxOccurs="1" → exactly once
minOccurs="0" maxOccurs="unbounded" → zero or more
minOccurs="1" maxOccurs="unbounded" → one or more
This allows the schema to express the shape of real data more accurately. A customer may have no secondary phone number, for example, while an order may be required to contain at least one line item.
Value Restrictions Make Types More Precise
Sometimes a built-in type is too broad.
Suppose an order status can only be one of three values:
pending
shipped
cancelled
Allowing any xs:string would also accept values such as banana, which clearly makes no sense for the application.
A restriction can define the permitted values:
<xs:simpleType name="OrderStatus">
<xs:restriction base="xs:string">
<xs:enumeration value="pending"/>
<xs:enumeration value="shipped"/>
<xs:enumeration value="cancelled"/>
</xs:restriction>
</xs:simpleType>
Other restrictions can constrain numbers, string lengths, and patterns. For example, a quantity might have a minimum permitted value, while an identifier might need to match a particular textual format.
These constraints turn an XSD from a description of rough document shape into something closer to an enforceable data contract.
Namespaces Prevent Naming Collisions
Large XML environments often combine information defined by different organizations or specifications. This creates a naming problem: two systems might both define an element called id, name, or address while meaning completely different things.
XML namespaces provide a way to distinguish them.
You will see this immediately in most XSD files:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
Here, xs is a prefix associated with the XML Schema namespace. That is why schema elements are written as:
<xs:element>
<xs:complexType>
<xs:sequence>
rather than simply <element> or <sequence>.
Schemas can also define target namespaces for the XML vocabularies they describe, making it possible for several vocabularies to coexist without relying on globally unique element names.
Well-Formed XML and Valid XML Are Different
This distinction causes a lot of confusion when working with XML.
A well-formed XML document follows XML’s basic syntax rules. Tags are properly closed, nesting is correct, attribute syntax is valid, and the document has the required structural characteristics.
For example:
<customer>
<name>Julia</name>
</customer>
is well formed.
But suppose an XSD requires both name and email:
customer
├── name required
└── email required
The XML above is still well formed, but it is not valid against that schema because the required email element is missing.
The relationship is easier to see like this:
XML Document
│
┌─────────┴─────────┐
↓ ↓
XML syntax XSD rules
│ │
↓ ↓
Well-formed? Valid?
Well-formedness asks whether the document obeys XML syntax. Schema validation asks whether the document obeys the particular structure and constraints defined for that document type.
Schema Validation Turns XSD Into a Contract
Once an XSD exists, an XML document can be checked against it through schema validation.
Suppose the schema requires:
customer
│
├── id integer, required
├── name string, required
├── email string, required
└── age integer, optional
Then this document can be checked before an application processes it:
<customer>
<id>1042</id>
<name>Julia Norton</name>
<email>julia@example.com</email>
<age>34</age>
</customer>
If id contains text where an integer is expected, a required element is missing, an element appears in an invalid position, or a restricted value falls outside the permitted rules, validation can report the problem.
This is particularly useful when XML moves between independent systems. Instead of discovering incompatibilities deep inside application logic, the document can be rejected at the boundary.
XSD Files Usually Live Separately From XML Data
XML schemas commonly use the .xsd extension:
customer.xml
customer.xsd
The relationship can be thought of as:
customer.xsd
│
│ defines rules for
↓
customer.xml
│
│ validated by
↓
XML Parser / Validator
│
├── Valid
└── Validation Errors
A single XSD can define rules used by many XML documents, and larger schema systems can be divided across multiple XSD files through imports and includes.
Keeping the schema separate also means the same contract can be shared by producers, consumers, development tools, testing systems, and documentation generators.
XML Schema and DTD Solve Similar Problems Differently
XSD was not the first mechanism for defining XML document rules. Document Type Definitions, or DTDs, can also describe permitted XML structures.
A DTD might contain syntax such as:
<!ELEMENT customer (name,email)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>
XSD expresses schema rules using XML syntax instead:
<xs:element name="customer">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
One major advantage of XSD is its richer type system. It can distinguish strings, integers, dates, booleans, decimals, and custom restricted types rather than treating most content as generic character data.
XSD also provides stronger namespace support and more detailed mechanisms for defining reusable and constrained structures. DTDs are simpler and remain part of existing XML systems, but XSD is much more expressive when detailed data validation is required.
Schema Generation Can Work in Both Directions
Developers do not always write every XSD manually. Many development tools can perform some form of schema generation.
Given an existing XML document, a tool may infer an initial schema:
Existing XML
│
↓
Schema Generator
│
↓
Generated XSD
This can be useful when working with a large existing XML format, although generated schemas usually deserve review. A tool can observe that one sample contains an age element, but it may not know whether that element is always required, whether the value has business restrictions, or whether other valid documents contain structures missing from the sample.
The opposite direction is also common. Development tools can read an XSD and generate classes or other code representing the schema:
customer.xsd
│
↓
Code Generator
│
├── Customer class
├── Address class
└── Order class
This is particularly useful in strongly typed application environments where XML documents need to be serialized into and deserialized from application objects.
XSD Is Really About Agreement
The syntax of XSD can look intimidating when you first encounter a large schema. There may be namespaces, named types, imported schemas, restrictions, nested complex types, and hundreds of element declarations spread across several files.
Underneath all of that, the purpose is fairly practical.
Two systems need to agree on what their XML means.
Producer
│
│ creates
↓
XML Document
│
│ must satisfy
↓
XSD Schema
│
│ understood by
↓
Consumer
The schema defines that agreement in a form software can check. Element declarations describe what can appear, complex types define hierarchy, simple types describe values, occurrence constraints control repetition, restrictions narrow acceptable data, and namespaces keep separate vocabularies from colliding.
XML by itself can tell a parser that <age>banana</age> is perfectly well-formed markup. XSD gives the system enough information to say that banana is not a valid integer and reject the document before the bad data travels any further.
That is what makes XML Schema Definition useful. It does not merely describe how XML is written; it describes which XML a particular system is willing to accept.