XSD File Documentation

---

Technical details

Feature	Value
Full name	XML Schema Definition
File extension	.xsd
MIME type	application/xml
Format type	XML-based schema document (plain text, UTF-8)
Developer	W3C (World Wide Web Consortium)
Introduced	2001 (XML Schema 1.0); 1.1 in 2012
Open standard	Yes — W3C Recommendation, royalty-free
Encoding	UTF-8 or UTF-16 text; optional BOM
Schema namespace	http://www.w3.org/2001/XMLSchema
Root element	<xs:schema> (prefix often xs: or xsd:)
Purpose	Define a vocabulary and validate XML instances against it
Type system	Simple and complex types; strings, numbers, dates, patterns, enumerations
Predecessor	DTD (Document Type Definition)
Alternatives	RELAX NG (.rng), Schematron
Validators	xmllint --schema, Xerces, .NET XmlSchema, XMLSpy
Uses XSD	WSDL/SOAP, ISO 20022, UBL, Office Open XML, SVG, GPX
Related extensions	.xml, .dtd, .rng, .wsdl, .xsl
Specification	w3.org/TR/xmlschema11-1/

What is an XSD file?

XSD stands for XML Schema Definition, the W3C’s language for describing and constraining the structure of XML documents. It became a W3C Recommendation in May 2001, with version 1.1 following in April 2012. An XSD is not data in its own right; it is a contract. It states which elements and attributes may appear in a given kind of XML, in what order, how many times, and carrying what data types, so that a parser can check a data file against the rules and report exactly where the data breaks them.

XSD replaced the older DTD (Document Type Definition) as the dominant schema language for three concrete reasons. It is itself written in XML, so the same tools parse the schema and the data. It is namespace-aware, so it can describe documents that mix vocabularies. And it has a real type system: strings, integers, decimals, dates, booleans, enumerations and regular-expression patterns, with minimum and maximum constraints. A DTD could say “this element contains text”; an XSD can say “this element contains an integer between 1 and 100.”

You meet XSD files as a developer or data analyst. One arrives alongside an XML file to explain the format you must produce or consume; it is bundled with an API or integration spec; or a tool generates it from sample XML. Behind the scenes XSD is the backbone of major data-exchange standards: SOAP web services reference XSD types through WSDL, and e-invoicing (UBL), banking messages (ISO 20022), Office Open XML, SVG and GPX all ship XSD schemas.

The xs:schema root and the XMLSchema namespace

Every XSD has a single root element, <xs:schema>, bound to the namespace http://www.w3.org/2001/XMLSchema. The prefix is only a convention: xs: and xsd: are both common, and any prefix works as long as it is mapped to that namespace URI. The root element also carries the attributes that govern the whole schema.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="https://example.com/orders"
    xmlns="https://example.com/orders"
    elementFormDefault="qualified">
  ...
</xs:schema>

The targetNamespace is the key attribute: it names the namespace that the elements and types this schema defines will belong to. When an XML instance says xmlns="https://example.com/orders", it is claiming to conform to a schema whose targetNamespace is that URI. elementFormDefault="qualified" controls whether locally declared elements must carry the namespace in the instance document, a setting that trips up many first-time schema authors. A schema with no targetNamespace is “no-namespace” and validates plain, un-namespaced XML.

Declaring elements, and the simple/complex type split

The two building blocks of an XSD are element declarations and type definitions. An element declaration says “an element with this name may appear, and its content matches this type.” A type definition describes the content. XSD draws a sharp line between two kinds of type.

A simple type contains only text: no child elements, no attributes. The built-in simple types include xs:string, xs:integer, xs:decimal, xs:date, xs:dateTime, xs:boolean and around forty more, and you can derive your own by restricting a base type. A complex type is anything that has child elements or attributes. Most of a real schema is complex types describing the shape of the document.

<xs:element name="order">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="id"       type="xs:integer"/>
      <xs:element name="customer" type="xs:string"/>
      <xs:element name="item"     type="ItemType"
                  minOccurs="1" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="priority" type="xs:boolean"
                  use="optional"/>
  </xs:complexType>
</xs:element>

Inside a complex type, a compositor controls child ordering. <xs:sequence> requires the children in the exact order listed; <xs:choice> allows exactly one of a set; <xs:all> allows them in any order. The minOccurs and maxOccurs attributes set cardinality: maxOccurs="unbounded" permits a repeating element, and minOccurs="0" makes one optional. Attributes are declared with <xs:attribute> and are optional or required through use. This small vocabulary — elements, sequences, choices, occurrence bounds and attributes — is enough to pin down the structure of almost any document.

Restriction facets: constraining a value

Where XSD goes well beyond DTD is in constraining the actual values, not just the structure. You derive a new simple type by restriction from a base type and attach facets that narrow what is allowed. This is how a schema encodes real business rules directly into the type system.

<xs:simpleType name="PostCode">
  <xs:restriction base="xs:string">
    <xs:pattern value="[0-9]{2}-[0-9]{3}"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="Rating">
  <xs:restriction base="xs:integer">
    <xs:minInclusive value="1"/>
    <xs:maxInclusive value="5"/>
  </xs:restriction>
</xs:simpleType>

Facet	Constrains
xs:pattern	A regular expression the text must match
xs:enumeration	A fixed list of allowed values
xs:minInclusive / xs:maxInclusive	Numeric or date range bounds
xs:length / xs:minLength / xs:maxLength	String or list length
xs:totalDigits / xs:fractionDigits	Decimal precision and scale
xs:whiteSpace	Whitespace handling (preserve, replace, collapse)

The xs:pattern facet uses XSD’s own regular-expression dialect, which is close to but not identical to Perl or JavaScript regex. Facets combine: a type can require both a pattern and a maximum length. This is why an XSD can reject an XML file not merely for a missing element but for a phone number in the wrong shape or a rating outside 1 to 5, and report precisely which value failed which facet.

Reuse: named types, include and import

Real schemas are built from reusable parts. A named <xs:complexType name="..."> or <xs:simpleType> is defined once and referenced by many element declarations through the type attribute, so a change to the definition updates every use. Named <xs:group> and <xs:attributeGroup> bundle common sets of elements or attributes for the same reason.

Two mechanisms pull in other schema files. <xs:include> merges another schema that shares the same targetNamespace, as if the definitions were written inline. <xs:import> brings in a schema from a different namespace, which is how one document can validly mix vocabularies (for example an invoice that embeds a digital-signature namespace). This composition is what lets large standards such as ISO 20022 or UBL ship dozens of coordinated schema files rather than one monolith.

How validation actually works

An XSD is inert until a validating parser uses it. Validation takes two inputs, the XML instance and the schema, and answers one question: does the instance obey every rule? The parser checks structure (are the right elements present, in the right order, within the occurrence bounds), types (does each text value parse as its declared type), and facets (does each value satisfy its constraints). On failure it reports the offending node and the rule it broke.

On the command line the standard tool is libxml2’s xmllint:

xmllint --schema schema.xsd data.xml --noout

The same job is done in code by Xerces (Java/C++), the .NET XmlReaderSettings with an attached XmlSchemaSet, or Python’s lxml. XML editors expose it as a “Validate” command, and an XML instance can also point at its schema itself through the xsi:schemaLocation attribute, which maps a namespace to the schema URL so a validator knows where to look.

Two related jobs are worth knowing because people often reach for “convert” when they actually want one of these. Code generation turns a schema into typed classes: Java’s xjc (JAXB) and .NET’s xsd.exe both read an XSD and emit source code that serialises to and from conforming XML. Sample generation produces a skeleton XML instance that satisfies the schema, which tools like XMLSpy and Oxygen offer. Neither is a file-format conversion; the XSD is already XML.

XSD against DTD, and against JSON Schema

DTD is XSD’s predecessor and its limits explain why XSD won. A DTD uses its own non-XML syntax, has no namespace support, and cannot type content beyond “text” and a few crude tokens. XSD fixed all three. Downgrading an XSD to a DTD is possible for legacy systems but loses data typing and namespaces, so it is rarely worth doing.

The modern comparison people ask about is JSON Schema, for REST APIs that carry JSON rather than XML. There is no lossless mapping between them: XSD has namespaces, attributes and strict element ordering that JSON Schema has no concept of, and JSON Schema has constructs that XSD lacks. Tools can approximate an XSD as a JSON Schema for interoperability, but treat the result as a starting point, not an equivalent.

Frequently asked questions

What is the difference between XML and XSD?

XML is the data; XSD is the rulebook that says what that data is allowed to contain. An XSD is itself written in XML and is used to validate XML files against a declared structure and set of data types. One schema typically validates many instance documents.

How do I open an XSD file?

It is plain XML text, so any text editor opens it. For comfortable reading use Visual Studio Code with the Red Hat XML extension, or Notepad++ with XML Tools; both add syntax highlighting, folding and validation. Dedicated tools such as XMLSpy or Oxygen add a graphical schema view.

Can I convert an XSD to XML?

The question reflects a misconception: an XSD already is an XML document, so there is nothing to convert. What people usually want is to validate an XML file against the XSD, or to generate a sample XML instance that conforms to the schema. Both are jobs any XML editor or validator can do.

References

• W3C — XML Schema Definition Language (XSD) 1.1 Part 1: Structures
• W3C — XML Schema Part 2: Datatypes
• Microsoft Learn — XML Schema (XSD) validation reference

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.