XML in 2026: Is Het Nog Relevant voor Moderne Ontwikkeling?

Eerlijk gezegd — als ik "XML" zie in 2026, is mijn eerste gedachte "legacy code". Maar dat is eigenlijk oneerlijk. XML drijft stilletjes enkele van de meest kritieke systemen ter wereld aan, en het gaat nergens heen. Laat me je laten zien waarom.

Waar XML Nog Steeds de Baas Is

Bankwezen en financiën: Elke keer dat je een bankoverschrijving doet in Europa, is de kans groot dat die via ISO 20022-berichten gaat — dat is XML. Financiële rapportages gebruiken XBRL (ook XML). We hebben het over biljoenen dollars die elke dag door XML-pijplijnen stromen.

Gezondheidszorg: HL7 FHIR gebruikt zowel JSON als XML, maar de oudere HL7 v2/v3-berichten waar de meeste ziekenhuissystemen op draaien? Puur XML. Patiëntendossiers, labresultaten, recepten — allemaal XML.

Je Office-documenten: Elk .docx-, .xlsx- en .pptx-bestand is eigenlijk een ZIP-archief vol XML-bestanden. Open er eens een — het is fascinerend (en een beetje beangstigend).

Android-ontwikkeling: Elk layoutbestand in Android is XML. activity_main.xml is waarschijnlijk het eerste bestand dat elke Android-ontwikkelaar aanmaakt.

Buildtools: Mavens pom.xml, .NETs .csproj-bestanden, Spring Framework-configuraties — XML zit diep in enterprise-toolchains verankerd.

Wat XML Kan Dat JSON Niet Kan

Namespaces: Stel je voor dat je elementen uit verschillende vocabulaires combineert in één document zonder naamconflicten. XML-namespaces maken dit mogelijk. Het is essentieel voor formaten als SVG ingebed in HTML, of het mixen van SOAP-headers met aangepaste payloads.

Gemengde inhoud: Probeer een alinea weer te geven waarin sommige woorden vetgedrukt zijn en andere cursief in JSON. Het is op z'n best onhandig. XML kan dit van nature omdat het ontworpen is voor documenten, niet alleen voor data.

XSLT-transformaties: Je kunt één XSLT-stylesheet schrijven die XML transformeert naar HTML, PDF, een ander XML-formaat of platte tekst. Het is een declaratieve transformatietaal zonder echt equivalent in de JSON-wereld.

Schemavalidatie: XML Schema (XSD) is expressiever dan JSON Schema op veel gebieden. Het kan elementvolgorde, complexe typehiërarchieën en veldoverschrijdende beperkingen afdwingen waar JSON Schema moeite mee heeft.

Een Praktijkvoorbeeld

Stel dat je een e-commercesysteem bouwt dat facturen moet genereren. Met XML + XSLT sla je factuurgegevens op in XML en pas je verschillende XSLT-stylesheets toe om te genereren: een HTML-versie voor de browser, een PDF-versie om af te drukken en een EDI-versie voor het leverancierssysteem — alles vanuit dezelfde brongegevens. Probeer dat maar eens met JSON.

XML-Namespaces in Actie

Namespaces zijn een van die XML-functies die verwarrend lijken totdat je ze echt nodig hebt. Hier is een praktisch voorbeeld — een SVG-icoon ingebed in een XHTML-document:

Zonder namespaces zou de parser niet weten of tot het HTML-vocabulaire of het SVG-vocabulaire behoort. Namespaces laten je vocabulaires vrij mixen in één document, en dat is iets waarvoor JSON simpelweg geen mechanisme heeft.

Veelgemaakte Fouten van Ontwikkelaars met XML

Na jaren werken met XML in productiesystemen zijn hier de valkuilen die ik het vaakst zie:

1. Encoding-declaraties negeren. Als je XML-bestand niet-ASCII-tekens bevat maar je de encoding-declaratie vergeet, zullen parsers UTF-8 of wat hun standaard ook is aannemen. Declareer het altijd expliciet:

2. Attributen gebruiken wanneer elementen logischer zijn. Attributen kunnen geen complexe structuren bevatten, kunnen niet herhaald worden en zijn niet gemakkelijk uit te breiden. Als een waarde later complexer kan worden, gebruik dan een kindelement.

3. Niet valideren tegen een schema. Ongevalideerde XML doorgeven is een recept voor stille fouten. Als je een XSD hebt, gebruik het. Het vangt dataproblemen op tijdens het parsen in plaats van slechte data door je systeem te laten verspreiden.

4. XML opbouwen door stringconcatenatie. Doe dit nooit — het is een injectiekwetsbaarheid die wacht om te gebeuren. Gebruik altijd een goede XML-bibliotheek of DOM-builder.

Prestatietips voor XML-Verwerking

XML-parsers komen in twee hoofdvarianten, en de juiste kiezen is erg belangrijk voor de prestaties:

• DOM-parsers laden het hele document als boom in het geheugen. Geweldig voor kleine tot middelgrote documenten waar je willekeurige toegang nodig hebt. Slecht voor grote bestanden — een 100MB XML-bestand kan 1GB+ RAM verbruiken als DOM-boom.
• SAX/StAX-parsers verwerken het document als een stream, één element tegelijk. Ze gebruiken bijna geen geheugen en zijn veel sneller voor grote bestanden. Het nadeel is dat je niet door het document kunt springen.

Hier is de vuistregel: als je XML kleiner is dan 10MB, is DOM prima. Boven de 10MB, overweeg streaming serieus. Boven de 100MB is streaming verplicht, tenzij je graag kijkt hoe je server zonder geheugen komt te zitten.

XML vs JSON: Snelreferentie

Een Korte Geschiedenis van XML

XML werd in februari 1998 gepubliceerd als W3C-aanbeveling. Het was ontworpen als een vereenvoudigde subset van SGML (Standard Generalized Markup Language), dat sinds de jaren 80 bestond maar berucht complex was. Het doel was een formaat te creëren dat zowel menselijk leesbaar als machinaal parseerbaar was, streng genoeg om ambiguïteit te vermijden, en flexibel genoeg voor elk domein. Het eerste decennium van de jaren 2000 was XML *het* data-uitwisselingsformaat. SOAP-webservices, RSS-feeds, Atom-feeds, XHTML — alles was XML. Toen kwam JSON en nam de web-API-ruimte over, maar XML behield elk domein waar zijn unieke functies (namespaces, schema's, transformaties) er echt toe doen.

De Moderne XML-Ontwikkelaar

De meeste ontwikkelaars werken tegenwoordig in hybride omgevingen. Ze gebruiken JSON voor web-API's en realtime communicatie, en XML voor documentverwerking, enterprise-integratie en regelgevingsnaleving. Beide formaten kennen — en weten wanneer je welke moet gebruiken — is een oprecht waardevolle vaardigheid.

XML-Beveiliging: XXE en Andere Valkuilen

Als er één ding aan XML is dat beveiligingsingenieurs wakker houdt, is het XXE — XML External Entity-aanvallen. En eerlijk gezegd zou het jou ook moeten bezighouden. XXE staat met goede reden op de OWASP Top 10-lijst, en het verrast nog steeds ontwikkelaars in 2026.

Zo werkt XXE: XML laat je "entities" definiëren — in feite variabelen — in de document type declaration (DTD). Een *externe* entity kan verwijzen naar een URL of een bestandspad op de server. Als de parser is geconfigureerd om externe entities op te lossen (veel zijn dat standaard), kan een aanvaller XML maken die willekeurige bestanden van je server leest:

Wanneer de parser dit verwerkt, vervangt hij &xxe; door de inhoud van /etc/passwd. Zomaar leest een aanvaller gevoelige bestanden van je systeem. Bij geavanceerdere aanvallen kunnen ze zelfs uitgaande HTTP-verzoeken doen vanaf je server (Server-Side Request Forgery), of een denial-of-service veroorzaken met de beruchte "billion laughs"-aanval — een recursieve entity-expansie die al het beschikbare geheugen opvreet.

De oplossing is eenvoudig: schakel externe entity-verwerking uit. Zo doe je dat in twee populaire talen:

Naast XXE moet je oppassen voor XML-injectie — waarbij gebruikersinvoer in XML wordt ingevoegd zonder goede escaping. Het is het XML-equivalent van SQL-injectie. Gebruik altijd een goede XML-builderbibliotheek in plaats van stringconcatenatie (wat ik al noemde in het gedeelte over veelgemaakte fouten, maar het is het herhalen waard omdat het *zo* belangrijk is).

De gouden regel: parse nooit onbetrouwbaar XML met standaard parserinstellingen. Schakel altijd expliciet externe entity-resolutie, DTD-verwerking en XInclude-verwerking uit. Behandel XML van de buitenwereld met hetzelfde wantrouwen als gebruikersinvoer in een SQL-query.

XPath: XML Bevragen als een Pro

Als je regelmatig met XML werkt en geen XPath gebruikt, doe je het op de moeilijke manier. XPath is een querytaal die speciaal is ontworpen voor het navigeren door XML-documenten, en het is ongelooflijk krachtig als je het eenmaal doorhebt.

Denk aan XPath als CSS-selectors maar dan voor XML. In plaats van handmatig door de DOM te lopen met geneste lussen, schrijf je een beknopte expressie die precies de nodes selecteert die je wilt. Hier zijn enkele praktische voorbeelden:

Zo gebruik je XPath in JavaScript en Python — de twee talen waar de meeste ontwikkelaars naar grijpen:

Iets wat het vermelden waard is: JSON heeft geen ingebouwde querytaal. Het dichtstbijzijnde equivalent is jq, dat fantastisch is maar een externe tool in plaats van een gestandaardiseerd onderdeel van het formaat. XPath is ingebouwd in het XML-ecosysteem — native ondersteund door browsers, beschikbaar in vrijwel elke programmeertaal, en gestandaardiseerd door het W3C. Het is een van XML's echte concurrentievoordelen.

XPath vormt ook de basis voor XSLT (dat nodes selecteert om te transformeren) en XQuery (een volledige querytaal voor XML-databases). Zodra je XPath leert, heb je een hele familie van XML-technologieën ontgrendeld.

XML in Branchespecifieke Standaarden

Ik noemde eerder bankwezen en gezondheidszorg, maar het bereik van XML in branchespecifieke standaarden gaat veel dieper. Hier is een rondleiding door domeinen waar XML niet alleen wordt gebruikt — het is *verplicht*:

Juridisch: De juridische sector leunt zwaar op XML voor rechtbankdossiers en zaakbeheer. LegalXML, ontwikkeld door OASIS, standaardiseert elektronische rechtbankindeling, juridische citaties en zaakmetadata. In de VS schrijven veel staatsrechtbanksystemen XML-gebaseerde e-filing-formaten voor. Als je legal tech bouwt, bouw je op XML.

Uitgeverij: Dit verrast veel mensen — elk EPUB-ebook dat je ooit hebt gelezen is gebouwd op XML. EPUB-bestanden zijn ZIP-archieven met XHTML-inhoudsbestanden (dat is XML), een OPF-pakketdescriptor (XML) en een navigatiedocument (XML). DocBook, een ander XML-formaat, is de standaard voor technische documentatie sinds de jaren 90. O'Reilly Media gebruikte jarenlang DocBook om hun boeken in meerdere uitvoerformaten te produceren vanuit één XML-bron.

Wetenschap en Wiskunde: MathML is de W3C-standaard voor het weergeven van wiskundige notatie in XML. Het wordt ondersteund door alle moderne browsers en is essentieel voor wetenschappelijke publicaties op het web. Dan is er Chemical Markup Language (CML) voor moleculaire structuren, Astronomical Markup Language voor sterrendata, en tientallen andere wetenschappelijke XML-vocabulaires. Wanneer precisie en ondubbelzinnige datarepresentatie belangrijk zijn — en in de wetenschap zijn ze dat altijd — levert XML.

Overheid en Inkoop: Universal Business Language (UBL) is een OASIS-standaard die door overheden wereldwijd wordt gebruikt voor inkoop, facturering en supply chain management. De e-factureringsrichtlijn van de Europese Unie schrijft in wezen UBL-gebaseerde XML voor bij business-to-government-facturering. Als je aan Europese overheden verkoopt, stuur je XML-facturen.

Luchtvaart: Het Aeronautical Information Exchange Model (AIXM) definieert XML-schema's voor luchtvaartgegevens — luchthavens, luchtruimten, navigatiehulpmiddelen, procedures. Elk vluchtbeheersysteem, elke luchtverkeersleiding-update, elk NOTAM (Notice to Airmen) raakt AIXM-data. Dit is een domein waar "laten we gewoon naar JSON overstappen" geen gesprek is dat iemand voert, omdat de veiligheidsimplicaties van een formaatmigratie enorm zouden zijn.

De rode draad door al deze industrieën? Ze kozen XML omdat ze sterke validatie nodig hadden, namespaces om vocabulaires te combineren, en een formaat dat decennialang kon evolueren zonder achterwaartse compatibiliteit te breken. Die vereisten zijn niet veranderd.

SOAP vs REST: Waarom XML-API's Nog Bestaan

Als je je carrière in het laatste decennium bent begonnen, denk je misschien dat alle API's REST met JSON zijn. Maar loop een grote bank, verzekeringsmaatschappij, telecombedrijf of overheidsinstantie binnen, en je vindt SOAP-webservices die kritieke bedrijfslogica verwerken. En daar zijn goede redenen voor.

SOAP (Simple Object Access Protocol) is een XML-gebaseerd berichtenprotocol met functies die REST+JSON simpelweg niet standaard biedt:

Sterke contracten via WSDL: Een WSDL-bestand (Web Services Description Language) beschrijft *alles* over een SOAP-service — operaties, invoer-/uitvoerberichtstructuren, datatypen, eindpunten. Je kunt automatisch clientcode genereren uit een WSDL in Java, C#, Python of vrijwel elke enterprise-taal. REST-API's hebben OpenAPI/Swagger, maar adoptie is vrijwillig. Bij SOAP is het contract de service.

Ingebouwde foutafhandeling: SOAP heeft een gestandaardiseerd fault-element met foutcodes, foutstrings en detailelementen. Elke SOAP-client weet precies hoe fouten te parsen. REST-API's? Elke API verzint zijn eigen foutformaat.

WS-Security: SOAP heeft een uitgebreide beveiligingsstandaard die versleuteling en ondertekening op berichtniveau ondersteunt — niet alleen op transportniveau (TLS). Dit betekent dat een SOAP-bericht via tussenliggende servers kan gaan terwijl het end-to-end versleuteld blijft. Dit is erg belangrijk in de financiële dienstverlening waar berichten via meerdere systemen worden gerouteerd.

Transacties en betrouwbaarheid: WS-AtomicTransaction en WS-ReliableMessaging bieden ondersteuning voor gedistribueerde transacties en gegarandeerde levering. Dit zijn moeilijke problemen die REST volledig aan de applicatieontwikkelaar overlaat.

Dat gezegd hebbende, SOAP heeft echte nadelen: de berichten zijn uitgebreid, de leercurve is steil, debuggen is pijnlijk, en de XML-overhead maakt het langzamer dan JSON voor eenvoudige CRUD-operaties. Voor nieuwe web-API's en microservices is REST+JSON bijna altijd de juiste keuze. Maar voor complexe enterprise-integraties — vooral in gereguleerde industrieën — blijven SOAP's ingebouwde contracthandhaving en beveiligingsfuncties oprecht waardevol.

Migreren van XML naar JSON: Een Praktische Gids

Op een bepaald moment in je carrière zal iemand je vragen een XML-gebaseerd systeem te migreren naar JSON. Voordat je "tuurlijk, makkelijk" zegt, laat me je de valkuilen laten zien die iedereen verrassen.

Attributenverlies: XML-elementen kunnen zowel attributen als kindelementen hebben. JSON-objecten hebben alleen properties. Bij het converteren van Dune, waar gaat id heen? Waar gaat format heen? Waar gaat de tekstinhoud heen? Gangbare conventies gebruiken @-prefixen voor attributen en #text voor tekstinhoud, maar er is geen universele standaard — en wat je ook kiest, het andere systeem moet jouw conventie begrijpen.

Typeconversie: XML is inherent tekstgebaseerd. De string "42" in XML kan een integer, float, string of postcode zijn. JSON heeft verschillende typen. Tijdens de migratie heb je expliciete type-mappingregels nodig, anders eindig je met strings waar je getallen wilde (of erger, getallen waar je strings wilde — dag voorloopnullen in postcodes).

Array-ambiguïteit: Deze is bijzonder verraderlijk. In XML, als een element één kind heeft, is het een enkel element. Als het meerdere kinderen met dezelfde naam heeft, zijn ze van nature een collectie. Maar JSON moet van tevoren weten of iets een array of een enkele waarde is. Overweeg: Widget — is item een string of een array met één element? Als een andere bestelling drie items heeft, verandert de structuur. Je JSON-consumer moet beide gevallen aankunnen.

Stappen voor een succesvolle migratie:

• Stap 1: Inventariseer alle XML-schema's en documenteer precies welke functies je gebruikt (namespaces, attributen, gemengde inhoud, CDATA-secties, verwerkingsinstructies).
• Stap 2: Ontwerp eerst je JSON-schema en beslis expliciet hoe je attributen, gemengde inhoud en arrays behandelt. Documenteer elke beslissing.
• Stap 3: Bouw een conversielaag (geen big-bang-herschrijving). Draai beide formaten parallel en vergelijk de uitvoer.
• Stap 4: Migreer consumers één voor één en houd de XML-eindpunten actief totdat iedereen is overgestapt.
• Stap 5: Draai parallelle systemen voor minstens één volledige bedrijfscyclus (maand, kwartaal of jaar afhankelijk van je domein) voordat je XML uitfaseert.

Wanneer NIET migreren: Als je XML veel namespace-mixing, XSLT-transformaties of XPath-gebaseerde bedrijfsregels gebruikt, kunnen de migratiekosten opwegen tegen de voordelen. Ook als je XML verplicht is door een regelgevingsstandaard (HL7, ISO 20022, UBL), zul je XML sowieso onderhouden — JSON toevoegen voegt alleen een tweede formaat toe om te ondersteunen.

XML-Tools Die Elke Ontwikkelaar Zou Moeten Kennen

Werken met XML hoeft niet pijnlijk te zijn als je de juiste tools hebt. Hier zijn degene waar ik op vertrouw:

xmllint: Wordt meegeleverd met libxml2 en staat waarschijnlijk al op je systeem. Het valideert XML tegen schema's, formatteert (pretty-print) XML en evalueert XPath-expressies — allemaal vanaf de commandoregel. Het is de curl van de XML-wereld: simpel, snel en overal.

Saxon: De gouden standaard voor XSLT- en XQuery-verwerking, ontwikkeld door Michael Kay (die letterlijk de XSLT 2.0- en 3.0-specificaties heeft geredigeerd). Als je serieuze XSLT-transformaties doet, is Saxon wat je wilt. De open-source Home Edition verwerkt XSLT 3.0 en XPath 3.1.

XMLSpy (Altova): Een commerciële XML-IDE die populair is bij bedrijven. Het heeft visuele schema-editors, XSLT-debuggers en database-integratie. Het is duur maar krachtig — vooral handig bij het werken met enorme XSD-schema's die onpraktisch zijn om handmatig te bewerken.

oXygen XML Editor: Mijn persoonlijke favoriet voor XML-intensief werk. Het ondersteunt XSLT-debugging met stapsgewijze uitvoering, XPath-evaluatie, schema-bewuste bewerking met auto-complete, en heeft uitstekende DITA- en DocBook-ondersteuning. Als je regelmatig XSLT schrijft, verdient oXygen zichzelf in een week terug.

xmlstarlet: Een commandoregel-XML-toolkit waarmee je XML kunt bevragen, bewerken, valideren en transformeren direct vanuit de terminal. Zie het als sed en awk maar dan voor XML. Het is perfect voor shellscripts en CI/CD-pipelines waar je waarden uit XML-configuratiebestanden moet halen of XML on-the-fly moet aanpassen.

Visual Studio Code met XML-extensies: Als je al in VS Code werkt, geeft de "XML"-extensie van Red Hat je schemavalidatie, auto-complete en formattering. Gecombineerd met de "XSLT/XPath"-extensie is het een verrassend capabele gratis setup voor af en toe XML-werk.

Probeer Het Zelf

Moet je de twee werelden overbruggen? Onze XML naar JSON Converter verwerkt de transformatie met behoud van datastructuur en typen. Als je XML debugt, maakt de XML Formatter zelfs de lelijkste XML leesbaar. En voordat je XML naar productie deployt, haal het door de XML Validator om structurele problemen vroeg op te sporen.