Ada Byron, de toren van Babel en XSL

Ada Byron, de assistente van Charles Babbage (de eerste computerfreak), schreef ooit het eerste computerprogramma. Na dit succes, zal ze ooit begonnen zijn aan haar tweede applicatie. En als die twee applicaties gegevens uitwisselden, was zij waarschijnlijk ook de eerste die geconfronteerd werd met de problemen van applicatie-integratie. Zij heeft nooit geweten (misschien wel gehoopt) dat hier ooit een speciale programmeertaal voor ontworpen zou worden. En ze kon zeker niet weten dat die taal de naam XSL (eXtensible Stylesheet Language) zou dragen.

Zij was dus de eerste die oplossingen voor applicatie-integratie moest bedenken. Applicatie-integratie impliceert gegevensuitwisseling. Gegevens die in de ene applicatie aangemaakt zijn, moeten naar de andere doorgestuurd worden. Indien beide applicaties met dezelfde programmeertalen en door dezelfde groep ontwikkelaars gebouwd zijn, dan is de kans groot dat ze dezelfde taal spreken. Maar dit is vaak niet het geval. De ene applicatie spreekt SQL, de ander EDI en de derde gebruikt IMS DL/I. Hierdoor kunnen we een integratieproject vergelijken met het bouwen van de Toren van Babel, een project dat faalde omdat er, net als bij de meeste integratieprojecten, omgegaan moest worden met vele verschillende talen.

Gelukkig zijn steeds meer producten (inclusief ERP-pakketten, relationele databaseservers en applicatieservers) in staat om een uniforme taal te spreken: XML (Extensible Markup Language). Of het nu gaat over de uitwisseling van een simpel telefoonnummer, een factuur of een complexe handleiding, XML is conceptueel rijk genoeg om die gegevensstroom te formaliseren. We kunnen de bronapplicatie de uitgaande gegevens als XML-document laten genereren en de doelapplicatie ook XML laten praten. Tot zover heeft XML ons al veel opgeleverd.

Maar wat nu als de uitgaande gegevensstroom afwijkt van de binnenkomende gegevensstroom? Het betreft wel dezelfde gegevens, maar ze zijn anders gestructureerd. Voordat de doelapplicatie de uitgaande gegevensstroom kan oppakken, zal een derde applicatie de structuur van de gegevensstroom moeten omvormen. U kunt dit transformatieprogramma schrijven in een willekeurige programmeertaal. Eigenlijk zijn de enige minimale eisen dat die taal instructies heeft om bestanden te lezen en te schrijven. Alle bekende talen, zoals Java, C++, VisualBasic, Cobol, Fortran en zelfs RPG, zijn flexibel genoeg om elke gewenste transformatie, hoe lastig ook, te programmeren. Wel zal dit leiden tot veel procedurele code en dus wordt dit lastig te onderhouden software. Misschien zijn talen als Perl en Python dan meer geschikt, omdat zij al veel standaard faciliteiten hebben om tekst te bewerken. 

Maar het aanbevolen alternatief is XSL. Deze taal is speciaal ontwikkeld om de structuur van documenten te transformeren. Het primaire toepassingsgebied is het transformeren van een XML of XML-achtig document naar een ander XML-document. 

De kracht van XSL is dat het een declaratieve taal is (in tegenstelling tot een procedurele taal). Dit betekent dat je het grootste deel van de tijd bezig bent met het programmeren van wat er moet gebeuren en niet zozeer hoe dat moet gebeuren. Wat dat betreft heeft XSL iets gemeen met SQL, wat ook een declaratieve taal is.

Natuurlijk kent XSL ook problemen. Het is nieuwe technologie, dus is er nog veel kritiek op de performance van de XSL-processoren. Dit zijn de tools die de XSL-programma's verwerken. Maar dat is een bekend probleem voor nieuwe technologie, en zeker een bekend probleem voor declaratieve talen. Het is namelijk de XSL-processor die onze declaratieve specificaties moet vertalen naar het "hoe". Hoe slimmer ze hierin zijn, hoe sneller de transformatie uitgevoerd wordt. Wel moet dit probleem op korte termijn opgelost worden.

Een ander nadeel is dat er enigszins kunstmatig getracht is van XSL zelf weer een XML-taal te maken. Hierdoor zien de programma's er onnodig complex uit. Dezelfde functionaliteit had in een taal gegoten kunnen worden met een eenvoudigere grammatica. Misschien schrijft iemand ooit nog een leesbare macrotaal die naar XSL vertaald kan worden.

Het laatste nadeel dat we hier willen noemen, is dat XSL geen algemene programmeertaal is. Het is geen vervanger voor Java en VisualBasic. Dat betekent wel dat er grenzen zijn aan mogelijke transformaties. 

Maar ondanks de nadelen heeft XSL veel te bieden. Het zal bij applicatie-integratie projecten de voorkeurstaal gaan worden om transformaties in te schrijven. Ada Byron en de aannemers van de Toren van Babel zouden jaloers op ons zijn.