Glossary

XML

XML can represent hierarchical data using custom elements, attributes, and namespaces. It is precise and extensible, but its parser must be configured securely and the data contract validated beyond syntax alone.

Short definition

A marked-up data document, not an HTML page or an automatically secure import.

An XML document has exactly one root element. An element can contain text, other elements, and attributes; for example, a product can carry an identifier and have name, price, and availability as its children. The XML declaration can specify the version and encoding, but above all the document must be well-formed: tags close correctly, nesting is coherent, and attributes are written properly.

Well-formed XML does not necessarily conform to the required catalogue or API message. A schema, such as XML Schema, can describe permitted elements and data types. The application must then also check business rules: whether the currency is valid, whether the product exists, whether the integration is authorized, and whether the price can actually be changed in the current state.

The problem it solves

Transferring hierarchical data between systems with a precisely defined structure.

XML is particularly useful when an integration contract relies on nesting, namespaces, or an existing XML schema.

product catalogues, availability feeds, and supplier price lists
exports of orders, invoices, and other documents to an external system
integration protocols and standardised messages with XML namespaces
configuration or project files when a particular tool requires XML
validatable data exchanges where the parties have agreed on a schema and versioning

Practical example

A securely processed XML product catalogue.

The supplier sends a single catalogue root and a stable external identifier for each product. The price is in a separate element with the currency as an attribute; after parsing, the application converts it to a suitable internal value and only then checks the import rules.

The example uses neither a DTD nor external entities. The recipient must still explicitly disable external entity resolution in the parser, apply size limits, and verify that the partner may modify the specific catalogue.

XML

<?xml version="1.0" encoding="UTF-8"?>
<catalog>
  <product id="SUP-42">
    <name>Trekingový batoh</name>
    <price currency="CZK">2490.00</price>
    <availability>in_stock</availability>
  </product>
</catalog>

How it works

From an XML file to a verified change in the application.

A secure import separates transport, constrained parsing, technical validation, and business decisions.

File acceptance and limits The service verifies the source, size, expected MIME type, and, where applicable, the signature. Neither the .xml extension nor a client-supplied Content-Type proves that a file is safe.
Secure parsing The parser operates without loading external entities or accessing networks and files unnecessarily. Depth and size limits protect the application's resources.
Structure validation The application checks the root, permitted elements, namespaces, required fields, and expected data types. XML Schema only helps with the rules it can actually express.
Conversion and business validation The price text is converted to a suitable monetary representation, availability to an allowed value, and the identifier is associated with a specific tenant or supplier.
Storage and traceability The import is processed idempotently, its result is recorded, and a safe error is returned. The entire sensitive document is not logged without a specific need and retention policy.

Key concepts

Elements, attributes, namespaces, and levels of validity.

XML offers more structural tools than a simple object format, so it is important to distinguish their roles.

Element and attribute

An element contains text or further structure, while an attribute adds a property to an element. The choice is not merely a matter of taste: the contract should specify where each piece of information belongs and how it can be extended.

Root and nesting

Every XML document has one root. Its tree of descendants naturally represents structures such as a catalogue, a product, and its variants, but excessively deep trees make both reading and processing harder.

Namespace

A namespace distinguishes identically named elements from different vocabularies. The URI in a namespace declaration generally serves as a namespace identifier, not as a URL the parser must visit.

Well-formed and valid documents

Well-formed XML follows the syntax. Valid XML also conforms to a defined DTD or schema. Neither level automatically verifies the business meaning of the data.

DTD and external entities

DTD is an older mechanism for defining structure. External entities must not be enabled for untrusted input: they can lead to XXE, unexpected resource access, or resource exhaustion.

Benefits and limitations

Expressive structure and schemas at the cost of greater complexity.

Benefits

hierarchical elements and namespaces express more complex integration vocabularies well
schemas can formalise part of the contract and generate validation or documentation
the format is widely supported in both legacy and current enterprise integrations
its text representation supports auditing and transport when correctly encoded

Limitations and mistakes

XML is often more verbose than JSON, and hand-written documents are more easily broken by incorrect nesting
a parser with external entities enabled can introduce a security vulnerability
schema validity does not replace type conversion, authorization, or business rules
namespaces and prefixes complicate queries and contract changes
large documents require limits or streaming instead of loading everything into memory

Practical use

Choose XML where its structure or established ecosystem provides a genuine benefit.

A supplier product catalogue may use XML because the supplier sends the same schema to multiple customers. For each file, the import service checks its size, parses the document securely, verifies the partner interface, and applies changes in batches. Simply loading XML into an object does not complete the import; prices, currencies, duplicates, and stock levels require their own rules.

JSON may be simpler for a newly designed, smaller HTTP API if XML namespaces or an established industry schema are not needed. This is not a contest between formats. The decision depends on clients, validation, operations, development tools, and whether the format represents a long-term public contract.

What to consider

Constrain untrusted XML first, then parse and validate it.

Security must not depend solely on the document looking like the expected catalogue.

disable external entities and DTDs where they are not needed; the parser should not access the network or local files without a reason
limit request size, element count, depth, and processing time according to the nature of the import
validate the permitted root, namespaces, elements, and value types before changing the database
convert textual values such as prices, dates, and booleans to explicit application types
use UTF-8 and document the XML declaration if the integration contract requires it
log the import identifier and error, not the entire sensitive XML document, including personal data, without a reason

Common questions

XML in practice

Is XML the same as HTML?

No. HTML defines the meaning of elements for the web in advance. XML is a general format in which the contract defines its own elements, attributes, and, where applicable, namespaces.

Is well-formed XML automatically valid?

No. Well-formed XML follows the syntax. Valid XML also conforms to a designated schema; even then, business rules must still be checked.

Why are external entities discussed in relation to XML?

Some XML mechanisms can reference external resources. Parsers must not load them for untrusted documents, to prevent XXE and unexpected resource consumption.

Should I use XML or JSON for a new API?

It depends on the clients and the contract. JSON is usually simpler for smaller HTTP APIs, while XML may be required by an existing industry standard, namespaces, or a schema.

How I work with integration data

I combine external data formats with secure imports, validation, and traceability.

For e-commerce and marketplace integrations, I address partner identity, idempotency, monitoring, and secure error handling alongside the format itself.

How I work with APIs and integrations Discuss your project without obligation