XML Integration Explained

Ask a room of younger developers about XML and you will get a small groan. It is verbose. It is heavy. The tooling feels like it belongs to a previous decade. And yet, if you open the hood on the systems that actually run large organisations, the banks, the utilities, the tax authorities, the logistics networks, the ERP platforms, you find XML everywhere. It carries SOAP web service payloads, it structures EDI-adjacent business documents, it holds the configuration of half the enterprise software on the planet, and it moves financial messages that clear billions in value every day. XML did not win because it is elegant. It won because it is precise, self-describing, and enforceable, and those three properties are exactly what serious integration needs. This guide sits inside the broader enterprise system integration pillar, and it explains XML the way a practitioner actually uses it.

The message up front: XML's verbosity is the price of its power. The angle brackets that everyone complains about are what let you validate a document against a formal contract, namespace it to avoid collisions, query it with XPath, and transform it with XSLT, all with mature, standardised tooling. When a payload has to be provably correct before a system will accept it, XML's strictness stops being a nuisance and becomes the whole point.

1. What XML is

XML, the Extensible Markup Language, is a text format for representing structured data using nested tags. It was standardised by the World Wide Web Consortium (W3C) in 1998, and the core specification has been remarkably stable ever since. At its simplest, XML lets you wrap a piece of data in a named tag, nest tags inside other tags to express hierarchy, and attach attributes to tags to carry extra detail. That is the whole idea, and its simplicity at the base is part of why it scaled to so many uses.

The word that matters most in the name is "extensible." Unlike HTML, which has a fixed vocabulary of predefined tags, XML defines no tags of its own. You invent the tags that fit your domain. An invoice document uses tags like <Invoice>, <LineItem> and <TotalAmount>; a maintenance work order uses <WorkOrder>, <Asset> and <Priority>. XML gives you the grammar of nesting, naming and attributes, and you supply the vocabulary. That combination of a fixed, universally understood syntax with a completely open vocabulary is what made it a lingua franca for machine-to-machine data exchange.

A well-formed XML document follows a small set of strict rules: every opening tag has a matching closing tag, tags nest cleanly without overlapping, attribute values are quoted, and there is exactly one root element wrapping everything else. This strictness is deliberate. A parser can reject a malformed document immediately and unambiguously, which means two systems built by two teams that have never met can still agree on exactly what a valid message looks like. That property, machine-verifiable structure, is the foundation everything else builds on.

Here is what a small, well-formed XML document looks like. Note that in this article the angle brackets are shown as entities so they render correctly in the browser, but in a real file you would type the literal characters:

Read that document and you already understand it without any external documentation. It describes a high-priority work order, WO-10482, against the asset Chiller-03, with a description and a due date. That self-describing quality is a genuine strength. The tags carry meaning, so the data explains itself to a human reader and to any parser that receives it. The cost, of course, is that the same information in a leaner format would take a fraction of the bytes, and that trade-off sits at the centre of every XML-versus-JSON debate later in this guide.

2. Where XML still dominates

It is easy to assume XML is legacy and that everything new is built on lighter formats. The reality on the ground in enterprise integration is more stubborn. There are whole categories of system where XML is not just present but genuinely dominant, and it is worth knowing them because you will meet them constantly.

• SOAP web services. The entire SOAP protocol is built on XML. Every request and response is an XML envelope with a header and a body, and the service contract is itself described in XML through WSDL. Enterprise middleware, government gateways, banking interfaces and older ERP integrations lean heavily on SOAP, and where there is SOAP there is XML by definition. For the protocol detail, see the SOAP API explained pillar.
• Financial and industry messaging. Standards such as ISO 20022, the backbone of modern payments and settlement messaging, are defined in XML with rigorous schemas. Healthcare, insurance, travel and supply-chain standards bodies have published XML message definitions that thousands of organisations must conform to. When an industry needs a shared, enforceable message format across many independent parties, XML with a published schema is still the default answer.
• EDI and business documents. Traditional EDI has its own compact formats, but a large and growing share of business-document exchange, purchase orders, invoices, dispatch advices, uses XML dialects because they are readable and validatable. This overlaps with file-based exchange patterns; see the file-based integration pillar for how these documents move between systems.
• Configuration and document formats. An enormous amount of software is configured in XML, from Java and .NET application settings to build tooling and deployment descriptors. Office document formats and countless data-interchange standards are XML under the surface. Even teams that would never choose XML for a new API still read and write it every day in their configuration files.

The pattern across all four is the same: XML dominates wherever many independent parties must agree on a strict, enforceable contract, and wherever a document has to be both human-readable and machine-verifiable. Those are precisely the conditions of serious enterprise integration, which is why XML has aged far better than its reputation suggests. If you integrate with government systems, banks, ERP platforms or industry standards bodies, you will be handling XML for years to come.

3. Structure: elements, attributes, namespaces

To work with XML confidently you need a clear mental model of its three structural building blocks: elements, attributes and namespaces. Elements are the tags themselves, the named containers that hold data or other elements. Attributes are name-value pairs attached to an element's opening tag, used for metadata about the element rather than its main content. Namespaces are prefixes that qualify element names so that two vocabularies can coexist in one document without their tag names colliding.

The distinction between elements and attributes is a perennial design question. The practical rule I use: put the actual data in elements, and use attributes for identifiers and small pieces of metadata that describe the element. An invoice number belongs in an attribute or a dedicated element; the customer address, with its own internal structure, belongs in nested elements. Attributes cannot contain nested structure, so anything that might grow richer over time is safer as an element. Getting this right early saves painful schema changes later.

Namespaces are the piece people find confusing, but the problem they solve is simple. If one industry standard defines an <Address> element and another standard also defines <Address>, and a single document needs both, how does a parser tell them apart? Namespaces attach each vocabulary to a unique identifier, usually written as a URI, so the two <Address> elements become unambiguously different. This is exactly why SOAP envelopes and multi-standard financial messages are dense with namespace prefixes: they are stitching several formal vocabularies into one document and keeping them cleanly separated.

The diagram below shows how these pieces fit together: a document is a tree of nested elements, elements carry attributes, and the whole tree is checked against a schema (an XSD) that defines which elements and attributes are allowed, in what order, and of what type.

That tree structure is not just a teaching aid. It is literally how XML parsers represent a document in memory, as a Document Object Model tree of nodes, and it is what XPath queries navigate and what XSLT transforms. Once you see XML as a validated tree rather than a stream of angle brackets, the rest of the ecosystem falls into place.

4. Schemas and validation (XSD and DTD)

The single most important reason XML endured in enterprise integration is validation. A schema is a formal, machine-readable contract that defines exactly what a valid document looks like: which elements are allowed, in what order, how many times each may appear, which attributes are required, and what data type each value must be. When two organisations agree on a schema, they have agreed on a precise, testable specification, and either side can reject a non-conforming message automatically before it does any damage.

There are two main schema technologies. The older is the Document Type Definition (DTD), inherited from XML's document-markup ancestry. DTDs can define element structure but have weak support for data types and no namespace awareness, so they are largely legacy today. The modern standard is XML Schema Definition (XSD), standardised by the W3C, which is itself written in XML and supports rich data types, namespaces, constraints, patterns and reusable type definitions. When people say "the schema" in a current enterprise context, they almost always mean an XSD.

Why this matters in integration. A schema turns "please send me valid data" into an enforceable, automated gate. The receiving system validates every inbound document against the XSD and rejects anything that does not conform, with a precise error pointing at the offending element. That is defensive integration at its best, and it is the capability the broader enterprise integration pillar keeps returning to: the more independent the parties, the more you need a contract a machine can enforce rather than a document a human has to trust.

Validation is where XML pulls decisively ahead of leaner formats for high-stakes exchange. The table below summarises the capabilities the XML ecosystem provides and what each one actually gives you in practice.

Look at that table as a whole and the point becomes obvious. XML is not just a data format; it is a mature ecosystem of standards for defining, validating, querying and transforming structured documents. Leaner formats give you the data-carrying part cheaply, but they do not come with a comparable, universally supported toolset for enforcing and reshaping that data. When those capabilities matter, XML is not overhead, it is the reason you chose it.

5. Transforming XML (XSLT and XPath)

Integration is rarely a matter of moving a document unchanged from one system to another. The sender's structure almost never matches the receiver's, so the payload has to be reshaped: rename elements, reorder fields, combine or split values, drop what the receiver does not need and add what it does. In the XML world there is a purpose-built, standardised way to do exactly this, and it is one of the format's genuine advantages.

XPath is the query language. It lets you address any part of the document tree with a compact path expression, selecting elements by name, position, attribute value or condition. Instead of writing procedural code to walk the tree and pull out the fields you need, you write a path that describes what you want and let the engine find it. XPath is used on its own for extraction and it is the addressing language inside XSLT.

XSLT, the Extensible Stylesheet Language Transformations, is the transformation language. An XSLT stylesheet is itself an XML document that describes how to turn an input document into an output: match patterns in the source with XPath, and emit the corresponding output structure. Crucially it is declarative. You describe the mapping rather than coding the mechanics, which makes transformations easier to review, version and reason about than the equivalent hand-written parsing and rebuilding. XSLT can produce another XML shape, or HTML for display, or plain text, from the same source document.

In practice this is why integration middleware and enterprise service buses lean on XSLT so heavily. A partner sends their invoice in their schema, an XSLT stylesheet transforms it into your internal invoice schema, and your system validates and ingests it. When the partner changes their format, you change the stylesheet, not your application code. That separation between the transformation contract and the business logic is a real maintainability win, and it is difficult to reproduce as cleanly in formats that lack an equivalent standard transformation language.

6. XML versus JSON

No honest discussion of XML can avoid the comparison with JSON, because for most new web and mobile APIs JSON has decisively won, and for good reasons. JSON is lighter, it maps directly onto the data structures of modern programming languages, and it is far less verbose for the same payload. If you are building a public REST API consumed by browsers and mobile apps, JSON is almost always the right default. I make that case in full in the JSON integration pillar.

But the comparison is not a simple case of the newer format being better at everything. The two formats optimise for different priorities, and the honest position is that each wins in its own territory:

• Verbosity and size. JSON wins clearly. The same data in JSON is smaller and quicker to parse, which matters for high-volume, latency-sensitive web traffic.
• Validation and contracts. XML's XSD is more mature and more widely deployed than JSON Schema, particularly across established industry standards. Where a rigorous, universally tooled contract is mandatory, XML still leads.
• Namespaces and mixed vocabularies. XML has first-class namespaces; JSON has no native equivalent. For documents that combine multiple formal standards, XML is structurally better suited.
• Transformation tooling. XSLT and XPath give XML a standardised, declarative transformation ecosystem with no direct JSON equivalent of the same maturity.
• Human and developer ergonomics. JSON is easier for developers to read and write by hand, which is a large part of why it took over the API layer.

The trap to avoid. Do not choose XML out of habit and do not choose JSON out of fashion. I have seen teams force JSON onto a partner integration that was built around a mandated XML industry standard, then rebuild half the validation and transformation machinery by hand and call it modernisation. If the contract, the standard or the partner requires XML, use XML. If you are building a fresh internal or public API with no such constraint, JSON is usually the lighter, friendlier choice. The format should follow the requirement, not the trend.

The realistic enterprise picture is that both formats live side by side. The customer-facing API layer speaks JSON, the back-end integrations with banks, government systems, ERP platforms and industry networks speak XML, and middleware translates between them. Knowing both, and knowing when each belongs, is a core integration skill rather than a matter of allegiance to one camp.

7. Best practices

XML is powerful, but that power is easy to misuse in ways that make documents fragile or painful to maintain. A handful of disciplines separate clean XML integration from the kind that generates endless support tickets.

• Always define and validate against a schema. An XML integration without an XSD is throwing away the format's greatest strength. Publish the schema, version it, and validate every inbound document against it. Reject non-conforming messages at the boundary with a clear error.
• Declare encoding explicitly. Start documents with the XML declaration and a stated encoding, almost always UTF-8. Encoding mismatches are a classic source of corrupted characters in cross-system exchange, and they are entirely avoidable.
• Use namespaces deliberately, not accidentally. When you combine vocabularies or publish a standard, use namespaces to keep them separate. When you do not need them, do not scatter half-configured namespace prefixes that confuse every downstream tool.
• Choose elements over attributes for real data. Reserve attributes for identifiers and small metadata. Anything that might gain internal structure later belongs in an element, so the schema can evolve without breaking changes.
• Escape special characters correctly. The characters &lt;, &gt; and &amp; must be escaped as entities inside text content. Broken escaping is one of the most common causes of malformed documents in hand-built payloads.
• Keep transformations in XSLT, not in application code. When you need to reshape a document, do it declaratively with XSLT so the mapping is visible, versioned and separate from business logic. This pays off every time a partner changes their format.
• Guard against XML-specific security risks. XML parsers can be attacked through external entity expansion (XXE) and entity-expansion denial of service. Disable external entity resolution on any parser handling untrusted input. This is a real, well-documented class of vulnerability, not a theoretical one.

None of these is exotic. They are the boring, repeatable habits that make XML integrations reliable, and their absence is behind a large share of the "XML is painful" complaints, which are usually really complaints about undisciplined XML rather than the format itself.

8. When to use XML

Pulling the practical guidance together, XML is the right choice in a fairly well-defined set of situations, and forcing it outside them is where teams get the reputation for masochism. Reach for XML when:

• A standard or partner mandates it. SOAP services, ISO 20022 payments, government gateways and many industry message standards are XML by definition. There is no debate to have; conform to the contract.
• Rigorous validation is essential. When a malformed or non-conforming message must be rejected automatically before it touches a downstream system, XSD validation is a decisive advantage.
• Documents mix multiple formal vocabularies. Where namespaces are needed to combine several standards cleanly in one document, XML is structurally the better fit.
• Complex transformations are part of the flow. When you are constantly reshaping documents between partner schemas, the XSLT and XPath ecosystem earns its keep.
• You are configuring software that expects it. Application configuration, build tooling and document formats that are XML-native are not worth fighting; write clean XML and move on.

Conversely, when you are building a fresh API with no external constraint, especially one consumed by browsers and mobile clients, JSON is usually the lighter, more ergonomic default, and I would not reach for XML out of habit. The Microsoft ecosystem shows both patterns living together: older SOAP endpoints speak XML while the newer surfaces favour JSON, as covered in the Business Central APIs and integrations pillar. The skill is not preferring one format; it is reading the requirement and picking the one that fits.

9. References

The XML family of standards is maintained by the World Wide Web Consortium (W3C), and the specifications below are the authoritative, primary sources. I have named the standards rather than linking to deep URLs, because the W3C reorganises document paths over time and the canonical way to reach any of these is to search the W3C site for the named specification.

• Extensible Markup Language (XML) 1.0, W3C Recommendation. The core specification defining well-formed and valid XML documents.
• XML Schema (XSD), W3C Recommendation. The standard for defining the structure and data types of XML documents.
• XSL Transformations (XSLT), W3C Recommendation. The language for transforming XML documents into other XML, HTML or text.
• XML Path Language (XPath), W3C Recommendation. The query language for addressing parts of an XML document, used standalone and within XSLT.

Final thoughts

XML is not fashionable, and it does not need to be. It earned its place in enterprise integration by being precise where precision is expensive to get wrong: self-describing structure, enforceable schemas, collision-free namespaces, and a mature toolset for querying and transforming documents. The verbosity everyone complains about is the visible cost of those guarantees, and on the systems that clear payments, file tax, run ERPs and connect thousands of independent parties, those guarantees are worth far more than the saved bytes.

The practitioner's posture is not loyalty to XML or to JSON, it is fluency in both and clear judgement about when each belongs. Use JSON where it is lighter and the ergonomics matter and no standard says otherwise. Use XML where a contract must be enforced, a standard mandates it, or a document has to be provably correct before a system will trust it. Learn the schema, respect the namespaces, keep the transformations in XSLT, and secure the parser, and XML stops being the format you dread and becomes what it has quietly been all along: one of the most dependable tools in enterprise integration. For the wider map of how these formats and protocols fit together, keep the enterprise integration pillar close.

Related reading: Enterprise system integration explained, JSON integration explained, SOAP API explained, File-based integration, Business Central APIs and integrations.