NDJSON naar XML omzetten

De twee formaten staan aan tegenovergestelde uiteinden van dezelfde vraag. NDJSON is ontworpen zodat geen regel van een andere afhangt: je kunt overal splitsen, hervatten na een fout, en verwerken zonder alles vast te houden. Een XML-document is het andere uiterste — het is pas geldig als de sluitende root-tag arriveert, dus het geheel is één eenheid van eerste tot laatste byte.

Dat is de eigenschap om rekening mee te houden, niet de elementnamen. Een omzetting van een grote export produceert één document dat als geheel verzonden, ontleed en geaccepteerd moet worden, en een fout waar dan ook faalt alles. Heeft het ontvangende systeem een berichtgroottelimiet, splits de bron dan eerst in batches.

De vorm ligt vast omdat de invoervorm vastligt. Een regelgescheiden bestand is altijd een lijst, en een lijst heeft geen eigen naam, dus het document is een root-element met één item-element per record. Elk veld wordt een kindelement genoemd naar zijn sleutel, en een genest object wordt geneste elementen eronder.

Er is geen optie om die twee namen tijdens de omzetting te wijzigen, en er is geen zinnige manier voor de omzetter om ze te raden — niets in een NDJSON-bestand zegt of de records bestellingen, claims of metingen zijn. De uitvoer is bewust het eenvoudigst correcte document.

Vrijwel elke XML-ontvangst noemt zijn recordelement in een schema: een Orders-document met Order-elementen, een Batch met Transactions. De twee generieke namen zijn dus tijdelijke aanduidingen, en ze vervangen is een klus van twee regels in elke editor.

Dat doen voor de eerste levering in plaats van na een afwijzing is de twee minuten waard. Een ontvangst die tegen een schema valideert, wijst het hele document af op de elementnaam, en meldt dat vaak niet duidelijk.

Een lijst in XML is altijd dezelfde tag meerdere keren geschreven, dus een record met drie tags levert drie tags-elementen naast elkaar op. Geen nummering, geen samenvoeging, geen beslissing namens jou — de structuur komt intact aan.

Dat is het sterkste argument voor XML boven de tabeldoelen voor hetzelfde bestand. Deze records naar CSV omzetten dwingt een keuze tussen genummerde kolommen, een samengevoegde string en extra rijen, en elk daarvan verliest iets.

JSON-sleutels kunnen van alles zijn: spaties, schuine strepen, een leidend cijfer, een valutateken. XML-elementnamen niet. De schrijver herschrijft in plaats van te falen — tekens die XML verbiedt worden underscores en een naam die met een cijfer begint krijgt er één voor.

Machinaal gegenereerde exports lopen hier vaker tegenaan dan met de hand geschreven exports. Alles gesleuteld op een datum, een metriekennaam of een klantreferentie levert herschreven namen op, en die herschrijving is stil. Heeft de ontvangst een schema, dan falen die elementen validatie op een naam die je niet herkent.

De verzoening die de tabelomzettingen uitvoeren, gebeurt hier niet, en hoeft ook niet. Elk item-element draagt precies de velden die zijn regel had, dus een gemengd gebeurtenissenbestand levert item-elementen van verschillende vormen op binnen één document — geldige XML, meestal ongeldig tegen een schema.

Een schema dat een vaste volgorde kindelementen declareert, wijst het eerste record af dat er een mist. Filter dan de bron eerst tot één recordtype, of voeg de ontbrekende elementen leeg toe.

Ampersands, punthaken en dubbele aanhalingstekens in een waarde worden ontsnapt, wat voorkomt dat een productomschrijving met opmaak erin het document voortijdig beëindigt. Al het andere, inclusief tekst met accenten, wordt als UTF-8 doorgeschreven.

Een JSON null wordt een leeg element: de tag staat er zonder iets ertussen. Sommige schema’s willen daar xsi:nil voor, sommige willen het element helemaal afwezig. Onderscheidt de ontvangst die, dan is dat een scriptmatige bewerking op de uitvoer.

Elke veldnaam verschijnt tweemaal per record — eenmaal in de openingstag en eenmaal in de sluitingstag — waar NDJSON hem eenmaal schrijft. Tel de inspringing erbij op, en een document van kleine waarden met lange veldnamen komt uit op twee tot drie keer de grootte van het bronbestand.

Op een SFTP-overdracht is dat irrelevant. Op een berichtenwachtrij met een groottelimiet bepaalt het hoeveel records in een batch passen. Het antwoord is bijna altijd compressie in plaats van herstructurering — dit soort XML comprimeert uitstekend met gzip.

Welgevormdheid eerst — elke XML-editor of commandoregel-parser bevestigt in een seconde of het document ontleedbaar is, wat altijd zou moeten kloppen. Schemavalidatie daarna, en verwacht dat de eerste poging faalt op de elementnamen, een ontbrekende naamruimtedeclaratie, of elementvolgorde.

Slaagt één document, dan staat de vorm van het werk vast: splits de bron in batches van de grootte die de ontvangst accepteert, zet elk om, pas dezelfde hernoemingen toe. Het eerste met de hand doen en de validatoruitvoer zorgvuldig lezen, maakt de rest mechanisch.

De omzetting draait in dit browsertabblad: het bestand wordt regel voor regel ontleed en het document wordt door een kleine schrijver in de pagina geschreven. Niets wordt geüpload, er is geen account of wachtrij, en het gratis niveau accepteert tot 100 MB.

De data die deze route neemt, is zelden onbelangrijk. Leveringen aan toezichthouders, banken, verzekeraars en partnersystemen zijn precies de bestanden met een vertrouwelijkheidsclausule eraan vast, en de omzetting door een onbekende webdienst laten lopen zou een tweede openbaarmaking zijn die niemand overeenkwam.