What Is XSD? XML Schema Definition With a Practical Example

Key takeaways

• XSD describes permitted XML elements, attributes, ordering, and values.
• An XML document can be well formed while failing validation against a particular schema.
• Namespace identity depends on the namespace URI and local name, not the chosen prefix.
• Validation requires the intended schema and does not replace authorization or application rules.

XSD stands for XML Schema Definition. It is a schema language for describing the permitted structure and content of XML documents.

Imagine a supplier sending order requests to a warehouse. Both systems understand XML, but that alone does not establish whether the quantity is required, whether it must be positive, or which identifier attribute should appear.

An XSD turns those expectations into rules a validator can check before the warehouse processes the order.

Well-Formed Is Different From Schema-Valid

This document follows XML syntax:

<order id="A104">
  <productCode>KB-42</productCode>
  <quantity>several</quantity>
</order>

Its tags are properly nested, and “several” is legitimate text. An ordinary XML parser need not reject it.

The warehouse, however, expects a positive integer quantity. Schema validation checks that more specific requirement.

“Valid XML” should therefore be qualified: valid against which schema and version?

A Complete Schema for the Request

The following schema deliberately uses no target namespace to keep the first example small:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="order">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="productCode" type="xs:string"/>
        <xs:element name="quantity" type="xs:positiveInteger"/>
        <xs:element name="note" type="xs:string" minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="id" type="xs:string" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

A matching document is:

<order id="A104">
  <productCode>KB-42</productCode>
  <quantity>2</quantity>
  <note>Leave at the receiving desk.</note>
</order>

The complex type permits children and an attribute. The sequence specifies child order. The note is optional, while the other two children occur once by default.

The W3C XSD structures specification defines these building blocks.

Types Constrain Values

The quantity type excludes zero, negative numbers, and words such as “several.”

By contrast, xs:string permits an empty string. If the warehouse requires a nonempty product code, it needs an additional restriction such as a minimum length.

XSD includes types for numbers, dates, booleans, and other values, plus facets that constrain lengths, ranges, and allowed values. The datatype specification describes their value and lexical rules.

A restricted enumeration can define a set of status strings, but it does not automatically define the transitions between them. That is a separate state-machine concern.

Occurrence Rules Are Explicit

Declaration choice	Effect
Default occurrence values	Exactly once
minOccurs="0"	Optional, with the default maximum of one
maxOccurs="unbounded"	Repetition allowed, with a default minimum of one
Both of those settings	Zero or more occurrences

Omitting an element, including an empty element, and using a nil value are different cases. A nil value requires appropriate schema support; optional does not automatically mean nullable.

For the warehouse, deciding whether an absent note differs from an empty note is part of the contract.

Namespaces Change Element Identity

A larger integration may place order elements in a target namespace.

Under XML namespace rules, the namespace URI and local name identify an element. Two different prefixes bound to the same URI can identify the same vocabulary.

Conversely, an unqualified order and an order in a namespace are different names. Adding a default namespace to the sample document would require a corresponding schema change.

A namespace URI is an identifier, not an instruction that a validator must download something from that address.

Choose the Schema Deliberately

An XSD file sitting beside an XML file does not guarantee validation occurred.

Configure the validator with the intended schema set and understand its support for XSD 1.0 or 1.1. Features added in 1.1 are not automatically available in every validator.

Schema-location attributes in incoming XML are hints, not a reason to let arbitrary input choose the application’s trusted contract. Control external resource resolution and schema retrieval according to the parser’s security guidance.

Validation Is an Entry Check

The warehouse still needs to confirm that product KB-42 exists, the supplier may place orders, and stock rules permit the operation.

Schema validation establishes neither permission nor the truth of the data. It establishes compliance with specified document constraints.

When changing the schema, consider existing producers and consumers. Adding a required element can break old senders; even an optional new element can upset a receiver using a stricter old schema.

Like JSON Schema, XSD is most useful when the declared contract, validator configuration, and deployed application behavior remain aligned.

XML tells you how the document is structured; a schema specifies which structure the interface accepts.