In de beter gesorteerde boekhandel bent u wellicht boeken over XML tegengekomen. Ook hier geldt: XML is in hoofdzaak toekomstmuziek. Maar om u te assisteren bij het meeblazen van uw partijtje, ook hier een paar opmerkingen. Even een voorbehoud: ik hoop dat ik het zelf een beetje begrijp.
Net als bij WAP is ook XML een onduidelijk fenomeen waarvan niemand nou precies weet wat het voorstelt. (Heerlijk, zo'n ongeordende bende! Sorry, jongens van het W3C...) Het staat dus voor "eXtensible Markup Language", dus zeg maar "uitbreidbare beschrijvingstaal". De grap is dat u uw eigen tags kunt maken. Alleen, dan gaat het niet om tags die qua weergave op het scherm iets teweeg brengen, maar om tags die een betekenis toekennen aan een deel van de tekst. (U kunt dus niet vlotweg de tag <UPSIDEDOWN>...</UPSIDEDOWN> introduceren.)
Dat klinkt erg abstract, en het is ook best lastig een voorbeeld te bedenken. Het idee er achter is ongeveer dat het raadplegen van klonten informatie via een webpagina steeds gebruikelijker gaat worden, en dat het voor snel en succesvol zoeken nuttig is dat er een zekere structuur in de aanwezige informatie is aangebracht.
Voor een normale zoekmachine is de regel: tekst is tekst. U tikt een zoekterm in, en het masjien gaat braaf zoeken of die term voorkomt in de pagina's in zijn collectie. Of dat ook gebeurt in de context waarin u dat zoekt kan hij niet beoordelen. Gevolg: u zult een aantal "hits" teruggemeld krijgen van pagina's waarin die term wel voorkomt, maar die niet slaan op waar u nou naar op zoek was. (Stelt u zich voor dat u iets over Stirling Moss -een coureur uit de jaren '50 en '60 van de vorige eeuw- wilt weten, en daartoe "stirling" en "moss" intikt. Best kans dat u op een bommenwerper uit de Tweede Wereldoorlog stuit. Ook interessant, maar niet erg efficieënt.) Met XML kunt u, als auteur, als het ware een "etiket" aan de naam "Stirling Moss" hangen: te weten "coureur".
Laten we maar weer de Double Clutch sleutelclub erbij halen, die een database van modern classics gaat aanleggen. Er zou tenslotte iemand eens willen weten hoeveel PK de Fort Cortina in 1966 had.
We gaan dan een soort "boom" bedenken van "gegevenstypen". De voor de hand liggende is "merk", bijvoorbeeld Ford. Dan verdeel je dat onder in "type" (Anglia, Cortina, Zephyr, etcetera). Verder is "cylinderinhoud" een item, "motorvermogen" en wat dies meer zij.
Die structuur bestaat dan uit, op het eerste niveau, het gegevenstype merk, en op het tweede type uit model. Daaronder zitten dan, op gelijke niveaus, de gegevenstypen cylinderinhoud, motorvermogen etcetera. De boomstructuur ziet er dan zo uit:
<merk>
<model>
<cylinderinhoud>
</cylinderinhoud>
<motorvermogen>
</motorvermogen>
</model>
</merk>
De invulling vindt dan plaats zoals u dat zou doen met de velden in een database: "Ford", "Corsair", "1664cc", "81pk".
Normaliter zou u deze gegevens in een tabel zetten. Een van de mogelijkheden lijkt te zijn dat u de opmaak van die tabel in één klap kunt regelen. Altijd een tijdrovend klusje, maar u zou hiermee nu kunnen zeggen "doe alle gegevenstypen "merk" met die-en-die opmaak". Dat gaat dan met een apart style sheet, met aparte opmaakinstructies, die zakelijk weergeven inhouden "geef alle teksten die zijn aangemerkt als 'model' weer in Bold". Een tweede mogelijkheid is dat u al deze dingen in een tekstbestand hebt, en in JavaScript een zoekfunctie maakt, die bijvoorbeeld alle Fords met meer dan 1500cc opzoekt, en van de resultaten een nette HTML-pagina maakt.
U zult na het bovenstaande vermoedelijk vooral een gevoel van "nou, zal wel" hebben gekregen. Een wat concreter voorbeeld is het volgende.
Er is op dit moment (eind 2006) een proces aan de gang geheten SEPA, wat staat voor Single European Payment Area. Het komt erop neer dat het de bedoeling is dat het betalingsverkeer in heel Europa even snel en soepel loopt als dat in Nederland nu het geval is. (We zijn in Nederland op dit gebied heel gewoon verwend!)
Bij een betaling van de ene rekening naar de andere (als u de rekening van uw loodgieter betaalt) zijn er een aantal gegevens nodig, bedrag, rekeningnummers, etcetera. U hebt een aantal posities voor een omschrijving, factuurnummer in dit geval. Op dit moment heeft elk land daarvoor zijn eigen standaard. Bij een grensoverschrijdende betaling leidt dat voortdurend tot problemen, bijvoorbeeld omdat er gegevens wegvallen, of reeds omdat elk land zijn eigen gewoontes heeft qua opbouw van een rekeningnummer. Van de omschrijving "your invoice 1234567" blijft dan, tegen de tijd dat de betaling het traject bank A > clearing land A > clearing land B > bank B heeft doorlopen, voor je het weet niet meer dan "your invoi" over.
SEPA introduceert hier niet alleen het u inmiddels vermoedelijk bekend IBAN-nummer, maar stapt ook over op een (veel flexibeler) format. Alle gegevens die nodig zijn om een betaling succesvol te verwerken -en dat zijn er nog heel wat meer dan u zou denken- worden van XML-tags voorzien, en in een vaste volgorde onder elkaar gezet. De inhoud van sommige van die "velden" ligt vast, bijvoorbeeld de lengte van een BIC-code. Zo'n ding is nu eenmaal gestandaardiseerd op x posities. Maar voor andere elementen wordt alleen een (ruime) maximale lengte voorgescheven.
U zult hier als consument niet erg veel van merken, behalve dat de schermindeling van uw betaalapplicatie er over een paar jaar wat anders uitziet. "Onder water" is er dan echter een grootschalige ombouwoperatie succesvol voltooid.
Eerlijk gezegd: ik zie het nut voor de bouwer van huis-tuin-en-keuken-websites totaal niet. Even los van het feit dat slechts de allernieuwste browsers ermee overweg kunnen, is het een hoop extra werk. De hoeveelheid te tikken code is gewoon groter. (Hoewel geavanceerde editors dat waarschijnlijk van u zullen overnemen, maar we hadden voor dit cursusje tenslotte afgesproken dat we het lekker primitief met Kladblok zouden doen.) U hebt niet slechts de "gewone" pagina, maar ook een (tamelijk ingewikkelde) pagina met de Document Type Defintion, een een pagina met de XSL-stylesheet. (Hoewel u die laatste hergebruikt en dus maar één keer hoeft te maken, dat wel.)
Maar als u zover mocht komen dat er grote klonten gegroepeerde gegevens gepresenteerd moeten worden (wellicht hebt u een omvangrijke fotoverzameling die u toegankelijk wilt maken op onderwerp, of zo) dan is het wellicht nuttig om er eens een boekje over open te slaan. Maar ik vind het nogal erg abstract. Maar logisch denkende lieden denken daar vast anders over. In elk geval, het W3C heeft er meer over op www.w3.org/XML/. En verder stuit ik nog op het XML Apache Project, dat gratis XML-tools zou leveren via www.apache.org. Mocht u zo ver komen, dan bent u me verre voorbijgestreefd.