Ja - jeg vil godt medgive, at CSV-filer fylder mindre, og at der kan være situationer, hvor de kan være at foretrække, hvis der er tale om tabulære datastrukturer med store mængder data. Men er der tale om mere end en enkeltstående udveksling, med lidt mere komplekse data, så er CSV-filer besværligere at manipulere og besværligere at validere.
Jeg gør mig derfor følgende antagelser i nedenstående argumentation:
- Der er tale om jævnlige udvekslinger af de samme data
- Udvekslingen skal i størst muligt omfang automatiseres
- XML-filer med et tilknyttet XML Schema med stærke datatyper giver automatisk validering.
- Med Schematron er det muligt at opsætte endda meget komplekse validering på tværs af data (integritetsregler som vi kender dem fra relationelle databaser).
- Med XSLT er det en leg at manipulere og præsentere data. En XML-fil kan omdannes til en CSV-fil med et meget simpelt XSLT stylesheet.
- Versionsinformation er tydelig via namespaces. Sker der en ændring i data, så fremgår det eksplicit af importfilen fordi namespace har ændret sig. Vi får mao. ikke importeret de forkerte data i de forkerte felter. Med en intelligent versioneringsstrategi er det endda muligt importere nye versioner af XML-filer såfremt ændringen er bagudkompatibel med tidligere XML-schemaer (lidt komplekst - men muligt fx i OIOUBL - og jeg forklarer gerne teknikken offline).
Jeg forstår ikke, at man vil give afkald på alle de fordele som man får foræret med XML-værktøjerne, blot for at spare lidt plads. Jeg er ikke i tvivl om at der findes domæner, hvor plads virkeligt er afgørende, og hvor antallet af transaktioner gør det nødvendigt at se kritisk på hvor meget ens XML fylder. Til militære formål og i kommunikationen med mobile enheder med små båndbredder er det helt sikkert tilfældet. I de fleste andre tilfælde er det min påstand, at den fleksibilitet man taber og den ekstra omkostning man påfører sig (ekstra kode) ikke kan opvejes af tilsvarende fordele når man vælge CSV-formatet.