Working with XML

Nobody starts a new project in XML any more, and almost everybody inherits one. Bank messaging runs on ISO 20022, healthcare runs on HL7, every Word and Excel file is a zip of XML, and a great deal of enterprise integration still speaks SOAP. The XML 1.0 specification has been stable since 1998, which is the reason all of that still works.

What makes XML harder than JSON is not the angle brackets, it is that XML carries features JSON has no equivalent for, and those features are where parsers go wrong. Namespaces mean an element's identity is a pair, not a name — and every junior developer tries to open a namespace URI in a browser at least once, expecting a page. It is an identifier, not an address, and nothing is served there. CDATA sections hold text that would otherwise need escaping, and a converter that collects only text nodes drops them entirely, because a CDATA section is node type 4 and a text node is 3.

Then there is the way the file reaches you. XML is text, so every editor on the machine offers to open it, and several of them will change it while doing so. A document opened and saved from a word processor comes back with curly quotes where the declaration wanted straight ones, and no parser will accept it afterwards. That failure looks like a corrupt file and is really an editor being helpful. If the document is meant to conform to a schema, XSD is what defines that, and it is a separate question from whether the file parses at all.

If you need to know whether a document is well formed before you go further, XML Validator will tell you where it stops being so. DOMParser is the browser API underneath most of the tools here, including this site's.