Format XML

XML (Extensible Markup Language) has been around for more than 25 years, but it's still woven into the infrastructure of modern software: from Office documents and Android layouts to SOAP APIs, RSS feeds, configuration files, and digital preservation workflows. It's not the cool kid anymore—that crown went to JSON—but XML remains critical wherever rigid structure, rich metadata, and long-term interoperability matter. The goal of this article is to explain XML thoroughly: where it came from, how it works, how we process and validate it, how it compares to newer formats, and how to use it safely and well in 2025 and beyond.

1. What XML actually is

XML is a simplified markup language for representing structured data and documents using nested elements and attributes. It's defined by the World Wide Web Consortium's Extensible Markup Language (XML) 1.0 Recommendation, which specifies the syntax for well-formed XML documents and describes how processors should handle them.

The XML spec describes XML as a restricted subset of SGML (Standard Generalized Markup Language), designed to be simpler to implement while preserving SGML's core power: representing structured text with explicit markup.

Some key properties make XML distinctive:

• Text-based and Unicode-aware. XML documents are plain text and rely on Unicode/ISO 10646 character sets, which makes them portable and language-independent.
• Self-describing. Tag names and attributes carry meaning. There's no separate schema required to make basic sense of the structure (though schemas make it much more powerful).
• Hierarchical. XML's tree structure maps directly to nested data, documents, and configuration hierarchies.
• Extensible. You invent your own tags and vocabularies; XML itself doesn't fix the set of allowed elements.

2. A brief history: from SGML to XML to the modern web

XML's roots lie in SGML, an ISO standard from the 1980s used heavily in publishing and technical documentation. By the mid-1990s, the web's HTML (which itself was SGML-based) was everywhere but too limited and tightly coupled to presentation.

Around 1996–1997, a working group including Jon Bosak, Tim Bray, C. M. Sperberg-McQueen, James Clark, and others began designing a simpler, web-friendly subset of SGML that could be parsed easily and reliably. The first XML 1.0 Recommendation was published in 1998, and XML quickly became the foundation for many early-web standards and protocols, including SOAP, WSDL, SVG, XSLT, and numerous industry-specific vocabularies.

Later, XML 1.1 refined some character-handling edge cases and control characters, but XML 1.0 remains the dominant variant in practice.

3. Core XML syntax: well-formed documents

The XML 1.0 spec defines a precise syntax for well-formed documents. At a minimum, a well-formed XML document:

• Has exactly one root element.
• Uses matching start and end tags.
• Properly nests elements (no overlapping tags).
• Uses quoted attribute values.
• Uses legal characters and encodings.

A tiny but valid document might look like:

<?xml version="1.0" encoding="UTF-8"?>
<note>
  <to>George</to>
  <from>Adam</from>
  <message>Hello XML!</message>
</note>

The XML declaration is optional, but it's the conventional way to state version and character encoding. The document element <note> is the single root. Text nodes, elements, attributes, comments, processing instructions, and entity references together form the tree structure described in the spec.

XML also distinguishes between well-formed and valid documents:

• A well-formed document follows the syntax rules.
• A valid document additionally conforms to a DTD or schema that constrains its structure and content.

4. Namespaces: mixing vocabularies safely

As XML vocabularies multiplied, name collisions became a problem: one vocabulary might use <title> for a book title; another for a job title. To avoid clashes, XML introduced namespaces, defined in the W3C Recommendation Namespaces in XML.

For example:

<book xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:title>XML in Depth</dc:title>
</book>

Here, dc:title is safely distinguished from any other <title> element by binding the dc prefix to the Dublin Core namespace URI. Namespaces are crucial in modern XML ecosystems: XSD, XSLT, SOAP, RSS, and Office Open XML all rely heavily on them.

5. Validation: DTDs, XML Schema, and more

5.1 DTDs

The original XML spec included Document Type Definitions (DTDs) as the canonical way to define the allowed structure of documents—permitted elements, attributes, entities, and so on. DTDs are compact and well-integrated into the XML prolog, but they're limited: they use a non-XML syntax, have weak typing, and struggle with namespaces.

5.2 XML Schema (XSD)

To address DTD limitations, W3C standardized XML Schema Definition (XSD), now at version 1.1, in XML Schema Definition Language (XSD) 1.1 Part 1: Structures. XSD is itself written in XML, supports namespaces, and provides rich typing (strings, numbers, dates, lists, unions), occurrence constraints, and complex content models.

Other schema languages exist—such as RELAX NG and Schematron—but XSD remains the de facto standard in many enterprise and standards-driven environments.

5.3 Why validation matters

Validation turns XML from structured text into contracts between systems. For example:

• Financial messaging specs define strict schemas for payment instructions.
• Standards like Office Open XML and RSS formalize their document formats with schemas.
• Build and configuration tools validate files like pom.xml or web.config to catch errors early.

6. Processing XML: DOM, SAX, and streaming

XML by itself is just text. To do anything useful, software must parse it into some model. The two classic processing models are DOM and SAX.

6.1 DOM: in-memory tree

The W3C's DOM Level 3 Core specification defines a language-neutral object model representing an entire document tree, with nodes for elements, attributes, text, comments, and more. DOM is random-access friendly, easy to reason about, and widely supported in libraries, but it requires the entire document to be held in memory.

6.2 SAX: event-driven streaming

The Simple API for XML (SAX) is an event-driven API that parses XML as a stream and fires callbacks for events like "start element" or "end element". It's described on the SAX Project site and in the Oracle SAX tutorial.

SAX processes documents in a single pass without storing the whole tree, making it extremely memory-efficient and ideal for large streams such as logs, message processing, or batch transformations. Pull-based streaming APIs such as StAX follow similar principles.

7. XPath, XSLT, and XQuery: querying and transforming XML

7.1 XPath

XPath is a compact query language for addressing parts of an XML document using path-like expressions such as /bookstore/book[1]/title. The latest version, defined in XPath 3.1, extends the model to also handle JSON data via maps and arrays and is backed by a large set of standard functions.

XPath is embedded in many tools: XSLT, XQuery, XML Schema assertions, and APIs across popular programming languages.

7.2 XSLT

XSL Transformations (XSLT) is a declarative language for transforming XML into other formats—XML, HTML, text, or even JSON in modern processors. The W3C's XSLT 3.0 Recommendation defines a template-based system that relies on XPath for pattern matching and selection.

Stylesheets are themselves XML documents using the XSLT namespace. XSLT 3.0 adds streaming capabilities for huge documents and improved integration with JSON and maps.

7.3 XQuery

XQuery is a full query language for XML repositories, defined in XQuery 3.1. It's designed for querying and transforming XML data collections, often stored in native XML databases or document stores, and uses FLWOR expressions (for, let, where, order by, return) to generate powerful result sets.

Together, XPath, XSLT, and XQuery form a rich toolkit for working with XML at scale, especially in publishing, digital humanities, e-government, and data integration contexts.

8. Real-world uses of XML today

Even as JSON dominates web APIs, XML is still deeply embedded in many systems and standards.

8.1 Document formats and standards

• Office Open XML (OOXML). Modern Microsoft Office documents (.docx, .xlsx, .pptx) are ZIP packages of XML files defined by ECMA-376 Office Open XML and related ISO standards.
• Digital preservation. Institutions like the Library of Congress treat XML (especially XML 1.0) as a stable, preservation-friendly format for representing structured digital content.
• Scholarly and technical markup. TEI, DocBook, and other domain-specific vocabularies are XML-based, enabling semantic markup and long-term archival.

8.2 Messaging and web services

• SOAP. The W3C's SOAP 1.2 spec defines an XML-based envelope for exchanging structured messages over protocols like HTTP.
• RSS and syndication. The RSS 2.0 specification defines an XML format for feed syndication, still widely used for blogs, news, and product feeds.

8.3 Configuration and build systems

• Maven POMs. Apache Maven's Project Object Model (pom.xml) is an XML file describing project metadata, dependencies, plugins, and build configuration, documented in the POM Reference and Introduction to the POM.
• Spring Framework XML config. Traditional Spring apps often define beans and wiring in applicationContext.xml or beans.xml files, an approach still described in the Spring reference documentation and tutorials like Java Guides.
• .NET configuration. ASP.NET and WCF rely on XML-formatted web.config and app.config files to configure endpoints, bindings, and behavior, as described in Microsoft's web.config documentation and WCF configuration guidance.

More generally, XML remains a common configuration format when validation and tooling are important, especially with XSD-backed schemas.

8.4 Mobile and UI layouts

In Android, UI layouts are typically declared in XML files under res/layout. Google's documentation explains that you write layouts using Android's XML vocabulary to nest views much like HTML, with each layout file containing a single root element.

9. XML vs JSON vs YAML

By 2025, JSON has clearly won the popularity contest for web APIs: one recent comparison article estimates JSON at around 87% of web API responses, with XML at 9% and YAML at 4%.

9.1 Strengths of XML

Compared with JSON and YAML, XML shines when you need:

• Rich schemas and strong validation. XSD lets you specify complex types, constraints, and relationships, and has a mature ecosystem of tools and validators.
• Mixed content and documents. XML was built for text-heavy documents where markup and text interleave; JSON and YAML are better at purely structured data.
• Deep metadata and extensibility. Namespaces and schemas allow version-tolerant documents where optional elements and attributes can be added without breaking older consumers.

9.2 Strengths of JSON and YAML

JSON is simpler to read and write, maps naturally to JavaScript objects, and is smaller on the wire. Tutorials frequently point out that JSON omits end tags, is more concise, and can be parsed natively in browsers without a dedicated XML parser.

YAML emphasizes human readability for configuration and is popular in DevOps tools like Kubernetes and Ansible, though its complexity and indentation sensitivity can introduce errors.

9.3 Choosing the right format

Modern guidance tends to be:

• Use JSON for most web APIs and client-server communication.
• Use YAML for developer-centric config in cloud/DevOps environments.
• Use XML when you need schema-driven documents, mixed content, existing XML ecosystems (SOAP, OOXML, WCF, Android layouts), or long-term archival where standardization and tooling are mature.

10. Security: XXE and other XML pitfalls

XML's flexibility comes with sharp edges, particularly around external entities and DTDs. The OWASP XML External Entity (XXE) Prevention Cheat Sheet documents how XXE vulnerabilities allow attackers to read local files, perform server-side request forgery, or cause denial of service by exploiting entity expansion.

Common attack vectors include:

• External entities referencing local or remote resources.
• Parameter entities in DTDs that expand into huge payloads.
• DTD retrieval over untrusted networks.

Mitigation guidance generally recommends:

• Disabling DTDs and external entities in parsers whenever possible.
• Using hardened parser settings or secure libraries that follow OWASP recommendations.
• Validating against schemas without enabling risky features.

Other security considerations include oversized documents (resource exhaustion), XPath/XQuery injection in systems that build queries from user input, and misconfigured XML-based configuration files leading to privilege escalation or code execution.

11. Design and best practices for XML

Used thoughtfully, XML remains a clean, robust way to model data and documents. Some practical guidelines:

• Model a clear tree. Design your XML around a stable conceptual tree (for example, <invoice> → <lineItems> → <lineItem>) rather than mirroring a relational schema directly.
• Choose elements vs attributes intentionally. Use elements for main content and structures; use attributes for metadata and flags.
• Use namespaces from the start. Even for small vocabularies, assigning a namespace (for example, xmlns="https://example.com/ns/invoice") avoids painful migrations later.
• Back your format with a schema. Provide XSD (or another schema language) and treat it as part of your public contract. Use schema validation in CI and at integration points.
• Keep it human-inspectable. Pretty-printing and comments help debugging, configuration, and long-term maintenance.
• Separate data from presentation. Use XML for structure and meaning, and transform it to HTML, PDF, or other formats with XSLT or other tools.
• Pick appropriate processing models. For small to medium documents and complex queries, DOM + XPath/XSLT may be ideal; for very large streams or constrained environments, use SAX, StAX, or event-driven processing.
• Harden parsers. Follow OWASP XXE prevention guidance and your language's security best practices when parsing untrusted input.

12. The future role of XML

In everyday web development, XML has largely ceded center stage to JSON and YAML. But in many domains—enterprise integration, document standards, configuration management, digital preservation, and legacy systems—rewriting everything into newer formats is either infeasible or undesirable.

Standards bodies like W3C and Ecma still maintain XML-based specifications such as XML 1.x, XML Schema, XPath, XSLT, XQuery, SOAP, and OOXML, and institutions like the Library of Congress continue to treat XML as an archival workhorse.

For developers, that means you'll likely interact with XML whenever you touch Office files, Android layouts, many Java enterprise stacks, .NET configuration, older SOAP/WSDL services, or standards-driven data exchange. Understanding XML's syntax, namespaces, schemas, and processing models remains a valuable skill, especially if you work in integration, infrastructure, or long-lived systems.

XML may no longer be the star of modern web APIs, but it's still a sturdy, well-specified, and heavily tooled foundation for a huge amount of software. Learning it deeply pays off whenever you need strong schemas, rich documents, or to navigate the vast landscape of existing XML-based standards.