XML Schema

If you're under 30, you might wonder why anyone cares about XML. Isn't JSON the standard? Why are we learning about a format from 1998?

Because XML is everywhere in the systems that actually run the world.

Your bank statement? SWIFT messages between banks use XML. Your doctor's electronic health records? HL7 FHIR. XML. The SOAP APIs that connect government agencies, insurance companies, and enterprise software? XML. Every Android app's layout? XML. Every Maven/Gradle build file? XML. Microsoft Office documents (.docx, .xlsx)? They're ZIP files containing XML.

In 2025, there are an estimated 4 billion SOAP API calls per day, all XML. The US healthcare system processes 2+ billion XML transactions annually. Governments worldwide mandate XML formats for tax filing, regulatory reporting, and data exchange.

You might never choose XML for a new project. But you will integrate with systems that use it. When you do, you'll need to validate that XML, make sure it has the right structure, the right data types, the right constraints. That's what XML Schema (XSD) does.

Think of it this way: JSON Schema is the bouncer at a trendy new startup's API. XML Schema is the security guard at a federal building. Different vibes, same job.

XML Schema Definition (XSD) is a way to describe the rules for a valid XML document, what elements can appear, in what order, with what attributes, and what types of data they can contain.

Here's a simple XML document, an employee record:

<employee>
 <name>Roni Das</name>
 <email>roni@example.com</email>
 <department>Engineering</department>
 <salary currency="INR">1500000</salary>
</employee>

And the XSD that validates it:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

 <xs:element name="employee">
 <xs:complexType>
 <xs:sequence>
 <xs:element name="name" type="xs:string"/>
 <xs:element name="email" type="xs:string"/>
 <xs:element name="department" type="xs:string"/>
 <xs:element name="salary">
 <xs:complexType>
 <xs:simpleContent>
 <xs:extension base="xs:decimal">
 <xs:attribute name="currency" type="xs:string" use="required"/>
 </xs:extension>
 </xs:simpleContent>
 </xs:complexType>
 </xs:element>
 </xs:sequence>
 </xs:complexType>
 </xs:element>

</xs:schema>

Yes, it's more verbose than JSON Schema. That's the universal complaint about XSD, and it's fair. But look at what it gives you:

xs:sequence means elements must appear in exactly this order. Name, then email, then department, then salary. Swap the order? Validation fails. JSON doesn't have ordering.

There are three of these keywords, and the third one is the case JSON Schema struggles with.