XML is verbose, not extinct — it's still what a lot of enterprise APIs, SOAP endpoints, and document formats speak. The useful skill isn't nostalgia for angle brackets, it's separating structural change from formatting noise when you read it, and preserving meaning deliberately when you convert it.
Read and diff it before you touch it
<item xmlns="urn:example" id="42"><name>Widget</name></item>
Pretty-print both documents before comparing them. A raw line diff lies the moment attribute order or whitespace changes — two semantically identical documents can produce a wall of red in a naive diff tool for no reason a reviewer would ever guess. Use a structural XML diff instead, one that compares element names, attributes, and text values rather than bytes; it's what actually tells you whether a vendor response changed in a way your integration needs to handle.
A namespace URI is an identifier, not necessarily a URL you can open. Two elements with the same local name but a different namespace are different elements —
xmlns="urn:example"above is a name, not an address, and pasting it into a browser tab tells you nothing.
XML-to-JSON conversion is not a neutral format swap either. XML distinguishes attributes, element order, namespaces, and mixed text; JSON objects do not. Decide the target shape first, then configure a converter to preserve what your consumer needs.
<order id="a17"><item sku="p1">Cable</item><item sku="p2">Adapter</item></order>
{ "id": "a17", "items": [
{ "sku": "p1", "name": "Cable" },
{ "sku": "p2", "name": "Adapter" }
] }
| XML feature | Conversion decision |
|---|---|
| Attribute | Promote to a named property |
| Repeated element | Always produce an array, even when there is one |
| Namespace | Keep a qualified key or map it in a schema |
| Mixed text / elements | Preserve order or reject as unsupported |
Run the source through an XML formatter first if you're eyeballing the diff by hand — indentation alone kills most of the false-positive noise before you even reach for a structural tool.
Do not let one-item arrays mutate
The classic converter bug yields an object for one <item> and an array for two. Consumers then need an ugly normalisation branch everywhere. Declare repeated elements as arrays in the target contract regardless of count.
XML parsers must disable or restrict external entity resolution for untrusted input. Format conversion is not a reason to accept XXE risk.
Validate against a real sample set, including empty elements, namespaces, and multiple children. JSON can be the better API surface, but the conversion earns its keep only when the meaning stays intact.