YAML's convenience has sharp edges
YAML is readable, which is why configuration moved to it, but its type inference is unusually aggressive. The most notorious case is the Norway problem: unquoted NO is interpreted as the boolean false under YAML 1.1, so a list of country codes silently converts Norway into false. The same applies to ON, OFF, YES and Y.
Version differences make this worse rather than better. YAML 1.2 narrowed booleans to just true and false, but many widely used parsers still implement 1.1 semantics, so behaviour depends on the library rather than on the document. Other inference traps: a version number like 1.20 becomes the float 1.2, losing the trailing zero, and a leading zero can trigger octal interpretation.
The defence is simple and worth applying by default — quote any string whose meaning matters. Tabs are also forbidden for indentation entirely, and since many editors insert them invisibly, a tab is a frequent cause of a parse error whose message points at the wrong line.
XML's structure and its security history
XML is more verbose and considerably more precise. It distinguishes elements from attributes, supports namespaces so documents from different vocabularies can be combined without collision, and has mature schema languages — XSD and RELAX NG — that validate structure, types and constraints far more thoroughly than JSON Schema typically does in practice.
Its five predefined entities must be used for the characters that would otherwise be read as markup, and unescaped ampersands are the most common cause of a document failing to parse.
The security consideration is XML External Entity processing. XML permits a document to define entities that load external resources, so a parser with external entity resolution enabled can be induced to read local files, make network requests from the server, or exhaust memory through recursive entity expansion — the billion laughs attack. Any parser handling untrusted XML must have external entity and DTD processing disabled; most modern libraries default to safe settings now, but older ones did not.
Choosing between them
For human-edited configuration, YAML's readability is a genuine advantage, and it is why Kubernetes, CI pipelines and application configuration converged on it. Its costs are the type-inference surprises and significant whitespace, which make large files fragile and awkward to diff.
For document-oriented data with mixed content — text with markup embedded in it — XML remains the better model, and it is the reason document formats and publishing standards still use it. Its namespace and schema machinery matters when several parties must agree on a format and validate against it independently.
For machine-to-machine data interchange, JSON has largely displaced both: simpler, unambiguous, and natively parsed everywhere. The JSON formatter covers that side. A reasonable rule is YAML where humans write it, JSON where programs exchange it, and XML where documents and formal schemas are the point.