[PHP5/XML/XSLT] 'Getting Started'

[BoomSmurf]

Ik heb nu een project in PHP waar simpelweg veel te veel uren voor staan (zeldzame luxe idd) dus ik denk, we gaan maar eens naar PHP/XML/XSLT kijken. Gewoonlijk maken we hier veel gebruik van PHP/Smarty maar oa door de discussie hier (ander topic) erover en omdat ik er al vaker over gehoord heb, wil ik dit toch ook wel eens proberen. Ik heb vaker met XML gewerkt (veelal produceren van XML aan de hand van een bestaand schema, niet echt van andere XML gebruik maken) dus ik ben daar geen complete newb in, maar XPath en XSLT zijn grotendeels nieuw voor me. Uiteraard wil ik het wel goed doen dus heb ik er een reeks vragen over:

- Voorbeelden - Nu heb ik wel al wat rondgekeken op het net naar voorbeelden, maar de meeste zijn redelijk kort. Men neme een simpel XML bestand en een kleine XSLT en daar wordt een kleine HTML pagina door geproduceerd. Ik zoek nu eigenlijk naar wat uitgebreidere voorbeelden, maar kan ze niet echt vinden. Als iemand een goed boek kan aanraden is dat natuurlijk ook altijd welkom

- Proces - De voorbeelden die ik bekeken heb nemen veelal een XML bestand en een XSLT bestand en gebruiken die samen. Aangezien die XML toch min of meer regelrecht uit je dblayer komt lijkt het mij dat je dblayer een DOM object teruggeeft en je daar meteen de XSLT (wel een echt bestand) op toepast. Of hoe wordt dit 'standaard' gedaan? Lijkt me niet echt handig om eerst een XML te gaan schrijven ergens en die vervolgens weer te gaan loaden om XSLT op uit te voeren (tenzij je het clientside doet natuurlijk)

- XSLT - Welk programma is het makkelijkst om XSLT te bouwen? ZDE lijkt me niet direct de beste keus hiervoor. Dreamweaver wellicht? Wat gebruiken jullie hiervoor?

- XML - Iets wat ik me al een tijdje afvraag bij XML (over het algemeen ligt er een schema vast waar ik me aan moet houden), wanneer besluit je van iets een attribuut te maken ipv een tag? Ik denk dan dat eigenlijk elke tag min of meer een attribuut is van de bovenliggende tag. Neem bijvoorbeeld een persoon. Die heeft een naam, geslacht, etc. Geslacht kun je als attribuut zien, maar ook als 'subtag'. Wanneer neem je welke? Verder, data heeft referenties naar andere tabellen, bijvoorbeeld bij Boek/Auteur. In het boek zal je het id van een auteur hebben. Ik neem aan dat het in gebruik zoals hier het makkelijkst is om zowel de boeken als de gebruikte auteurs in één XML eruit te gooien voor gebruik van de XSLT dan om twee verschillende XMLs te gebruiken (twee verschillende lijkt me 'mooier', maar ligt implementatiegewijs omdat de data dynamisch is weer een stuk lastiger). Of is het dan weer makkelijker om in het boek de auteur id te vervangen door de auteur data? (lijkt me niet, dubbele data, plus mogelijke referenties naar andere tabellen die je dan ook weer zou moeten includen, etc). Wat is hier wijsheid?

[Config]

Het idee was oorspronkelijk dat je inderdaad een XSLT en een XML file naar de client shoot, welke de zaak dan zelf parsed. Dit lijkt mij een slechte ontwikkeling, want op deze manier wordt het wel heel erg makkelijk om andermans data te verzamelen. Ik zou daar voorlopig van afblijven.

Verder raad ik je aan een boek te kopen dat meerdere aanverwante onderwerpen behandeld, zodat je een goede basis hebt waarmee je aan de slag kunt. Ik heb zelf een boek van Wynn's (zo'n dikke rode) die veel behandeld.

XML attributen zijn lame imo, ik zou alles tags maken. Wel zo helder. Wat betreft je voorbeeld over de boeken: de business logic moet niet in XSLT gaan zitten imo. Het is minder krachtig dan menig server-side talen en je raakt zo wel je macht kwijt op de client. Verschillende browsers pakken de zaak ook verschillend op, het is gewoon nog niet volwassen genoeg.
De dubbele verwerking (DB->XML->HTML) komt omdat je XML gebruikt waarvoor het eigenlijk niet is bedoeld: samenwerking verschaffen van systemen die al prima samenwerken (ik ga even uit van PHP/MySQL). XML is juist voor remote systemen/verschillende talen (ik noem bijv. een command line python script dat een php script assisteert)/etc. Als je gewoon scricte HTML wilt moet je natuurlijk ook even kijken naar XHTML.

[hamsteg]

Overbodig maar bovenstaand commentaar komt uit mijn hart!

Het geforceerde XML gebruik begint mij een beetje de keel uit te hangen ... denk eens logisch na en gebruik wat je nodig hebt (requirements), niet wat de hype is. Voor veel Client-Server gebruik is XML overbodig. Server-Server gebruik dan praat je over hele andere dingen en kan het zeer nuttig zijn (maar ook niet automatisch). Een deel van je database naar een client sturen zodat deze zelf hem kan processen is voor mij een beetje onnatuurlijk en geef je een kijkje in de keuken.

[crisp]

Config schreef op maandag 14 augustus 2006 @ 15:25:
Het idee was oorspronkelijk dat je inderdaad een XSLT en een XML file naar de client shoot, welke de zaak dan zelf parsed. Dit lijkt mij een slechte ontwikkeling, want op deze manier wordt het wel heel erg makkelijk om andermans data te verzamelen. Ik zou daar voorlopig van afblijven.

Ik zou sowieso ver wegblijven van clientside transformatie; de webbrowser wereld is geen homogene omgeving, not to mention dat je documenten totaal inaccesible zijn voor bijvoorbeeld searchengines omdat XML itt HTML geen vast gedefinieerde semantiek heeft.

[...]
De dubbele verwerking (DB->XML->HTML) komt omdat je XML gebruikt waarvoor het eigenlijk niet is bedoeld: samenwerking verschaffen van systemen die al prima samenwerken (ik ga even uit van PHP/MySQL). XML is juist voor remote systemen/verschillende talen (ik noem bijv. een command line python script dat een php script assisteert)/etc.

True, in dit geval is het een extra tussenlaag die eigenlijk overbodig is.

Als je gewoon scricte HTML wilt moet je natuurlijk ook even kijken naar XHTML.

XHTML is niet stricter dan HTML; XHTML is niets anders dan de XML-serialisatie van HTML4.01, en is juist door de beperkingen van XML tov SGML op sommige punten zelfs minder strict. Not to mention dat het door z'n beperkingen (o.a. geen error-correction) en het feit dat XHTML niet ondersteund wordt door 's werelds meest gebruikte browser niet het meest logische formaat is om webpagina's in op te maken

[Cyphax]

Op mijn werk wordt alle XML en XSLT met XMLspy gedaan. Die kan transformaties uitvoeren voor je, is een fijne editor voor dit soort zaken. Voor puur een webpagina zou ik niet de tussenstap van XML gebruiken, maar als je de output van de database wellicht ook nog ergens anders voor zou willen gebruiken kon het weleens handig zijn. Een ander voordeel van het XML-gebeuren is dat je met schema's (XSD) de boel kunt valideren en ervoor kunt zorgen dat de output van je database altijd voldoet aan jouw eisen. En als je XSL stylesheet in orde is krijg je ook consistente output van een transformatie.
Het heeft voordelen maar ook nadelen (overhead) en het hangt een beetje van je project af of het ee nuttige tussenweg is.

[Config]

Ohw dat wist ik nog niet allemaal crisp .

XML is prachtig en krachtig en drachtig, maar niet voor elke situatie inzetbaar. Niettemin is het de toekomst (want: connectivity/synchen/remote werken (RSS...)/etc) worden steeds belangrijker! Leer het dus wel .

[BoomSmurf]

Even ter verduidelijking: ik was niet van plan zowel de XML als XSLT naar de client te sturen, maar met behulp van de XSLT de data in de XML op de server om te zetten naar HTML.

En tja, XML is hier een overbodige 'extra laag', dat heb je toch wel. Je hebt je db objecten, je logic objecten en je templates. Als je smarty gebruikt dan wordt de data via het smarty object ook nog een keer opnieuw 'ingedeeld' voor het in de template komt. Wat dat betreft heb je de overbodig laag toch wel, of het nu in de vorm is van smarty data of XML.

Nu is het voor dit project niet zo belangrijk, maar de meeste 'nieuwe' dingen hier worden in het framework wat we hier gebruiken ingebouwd zodat we geen dingen voor elk project dubbel gaan doen. Ik weet dat voor een project wat we over een aantal maanden gaan doen, server-server XML belangrijk gaat worden, alsmede veel RSS/Atom feeds en PDA/mobile accessability. De database structuren en opbouw die we al aanhouden lenen zich voor dit laatste erg goed. We zaten hier al een beetje over te denken en kwamen er toen op uit dat het makkelijkst zou zijn hier een redelijk gestandaardiseerd 'tussenobject' voor te hebben dat met simpele templates de output genereert. Ik denk dat juist hiervoor XML/XSLT perfect zou zijn. De XML als geschikt tussenobject, met een metaobject erbij wat een aantal simpele regels definieert waar een deel van de XSLT's automatisch door gegenereerd kunnen worden, en de XSLT als templates met als voordeel dat het ook deels als doel heeft andere XML te generen (RSS/Atom, en eventueel de XML in iets andere vorm voor remote), wat weer moeilijker is met smarty. Ook 'gestandaardiseerde' simpele mobile versies van pagina's kunnen op deze manier makkelijk gebouwd worden denk ik. Veel vliegen in één klap denk ik dan. Of maak ik nu ergens een gigantische denkfout

[Verwijderd]

Config schreef op maandag 14 augustus 2006 @ 15:25:
Het idee was oorspronkelijk dat je inderdaad een XSLT en een XML file naar de client shoot, welke de zaak dan zelf parsed. Dit lijkt mij een slechte ontwikkeling, want op deze manier wordt het wel heel erg makkelijk om andermans data te verzamelen. Ik zou daar voorlopig van afblijven.

Met een HTML parser kunnen ze die data toch wel uit je webapp halen, ookal kost het ze een half uurtje meer. Security by obscurity werkt niet.

XML attributen zijn lame imo, ik zou alles tags maken. Wel zo helder. Wat betreft je voorbeeld over de boeken: de business logic moet niet in XSLT gaan zitten imo.

Attributen zijn helemaal niet lame, ze voorkomen gewoon dat je lamme <, > en / toetsen (en vingers) krijgt. Wanneer je ze moet gebruiken is idd niet altijd even duidelijk gedefineerd, maar meestal helpt CommonSense[tm] een hoop. Gewoon attributen gebruiken, tenzij het niet mooi lijkt in je document (door teveel attributen bij een tag, free-form parameters in attributen, etc).

Het is minder krachtig dan menig server-side talen en je raakt zo wel je macht kwijt op de client. Verschillende browsers pakken de zaak ook verschillend op, het is gewoon nog niet volwassen genoeg.

Macht kwijt op de client? Je kunt nog steeds kiezen precies wat voor model data je rondstuurt als XML hoor... Ook HTTP responses zijn nog steeds voor jou om te beinvloeden. Verschillende browsers die het anders parsen is een issue, maar de drie groten (MSHTML, Gecko en KHTML) implementeren het allemaal goed. Ook zijn er meerdere tools om de XSLT serverside te processen indien de client een AGENT is die geen XSLT support (lynx, googlebot, etc). Je hebt dus off-loading naar de client en een fallback.

De dubbele verwerking (DB->XML->HTML) komt omdat je XML gebruikt waarvoor het eigenlijk niet is bedoeld: samenwerking verschaffen van systemen die al prima samenwerken (ik ga even uit van PHP/MySQL). XML is juist voor remote systemen/verschillende talen (ik noem bijv. een command line python script dat een php script assisteert)/etc. Als je gewoon scricte HTML wilt moet je natuurlijk ook even kijken naar XHTML.

Sorry, maar ik vind dit uitermate kort door de bocht. XML is helemaal niet slechts ontworpen om 'systemen te laten samenwerken'. XML is ontworpen om een standaard manier te hebben om data te formatteren, zodat zaken als transformaties bijvoorbeeld mogelijk zijn met een enkel tooltje ipv vierhonderd voor elk formaat data.

Die 'dubbele verwerking' is trouwens niet iets wat je app veel slomer gaat maken, omdat browsers (zoals hierboven beschreven) het veelal zelf handlen. Ook helpt het je bandbreedte te besparen, omdat browsers de XSLT sheet cachen, waardoor dus _alleen_ nieuwe model data over het netwerk wordt gestuurd. Ook serverside processen is heel erg snel: XSLT is vooral een beschrijvende taal. Het enige wat het ding doet is wat output combineren.

XSLT biedt ook gewoon een hele mooie abstractie van de View. Kwestie van een andere XSLT sheet eroverheen en je kunt bijvoorbeeld zonder moeite PDF's bouwen van je documenten.

[Config]

BoomSmurf schreef op maandag 14 augustus 2006 @ 16:23:
Even ter verduidelijking: ik was niet van plan zowel de XML als XSLT naar de client te sturen, maar met behulp van de XSLT de data in de XML op de server om te zetten naar HTML.

En tja, XML is hier een overbodige 'extra laag', dat heb je toch wel. Je hebt je db objecten, je logic objecten en je templates. Als je smarty gebruikt dan wordt de data via het smarty object ook nog een keer opnieuw 'ingedeeld' voor het in de template komt. Wat dat betreft heb je de overbodig laag toch wel, of het nu in de vorm is van smarty data of XML.

Nu is het voor dit project niet zo belangrijk, maar de meeste 'nieuwe' dingen hier worden in het framework wat we hier gebruiken ingebouwd zodat we geen dingen voor elk project dubbel gaan doen. Ik weet dat voor een project wat we over een aantal maanden gaan doen, server-server XML belangrijk gaat worden, alsmede veel RSS/Atom feeds en PDA/mobile accessability. De database structuren en opbouw die we al aanhouden lenen zich voor dit laatste erg goed. We zaten hier al een beetje over te denken en kwamen er toen op uit dat het makkelijkst zou zijn hier een redelijk gestandaardiseerd 'tussenobject' voor te hebben dat met simpele templates de output genereert. Ik denk dat juist hiervoor XML/XSLT perfect zou zijn. De XML als geschikt tussenobject, met een metaobject erbij wat een aantal simpele regels definieert waar een deel van de XSLT's automatisch door gegenereerd kunnen worden, en de XSLT als templates met als voordeel dat het ook deels als doel heeft andere XML te generen (RSS/Atom, en eventueel de XML in iets andere vorm voor remote), wat weer moeilijker is met smarty. Ook 'gestandaardiseerde' simpele mobile versies van pagina's kunnen op deze manier makkelijk gebouwd worden denk ik. Veel vliegen in één klap denk ik dan. Of maak ik nu ergens een gigantische denkfout

Voor server-server communicatie is XML uitermate geschikt. Bijvoorbeeld met SOAP, een tool waarmee je specifieke informatie kan opvragen en sturen. XSLT komt niet voor tussen de servers.
Zodra je mobiele versies gaat maken van websites heb je het dus over communicatie van 1 set data naar meerdere andere componenten (PC/PDA/GSM/whatever), en daarbij kan XML ook heel goed van pas komen. Als je echter alleen maar pagina's voor 1 soort client maakt is het overbodig.

[prototype]

Ter uitbreiding op mauritsd's antwoord wil ik ook nog even zeggen dat je door die volgens config en crisp 'onnodige abstractielaag' die xml levert, toevallig wel mooi dus bij overstap van platform gewoon je XSL's nog kan behouden.

[djc]

Ik gebruik al jaren XSLT als templating-laag in mijn PHP apps. Hoewel dat niet altijd evenveel oplevert is het wel een goede methode om je view-laag strak gescheiden te houden van je controller laag en kan je er soms wel vette dingen mee doen (zoals transformaties naar Atom of RSS in plaats van XHTML, of, zoals iemand al aanhaalde, naar PDF via XSL-FO). Daarnaast kan het handig zijn als je er iets van REST-style web-services bij wil gaan bouwen, omdat je dan als het goed is al direct een keurige XML-representatie van je resources hebt.

Ik gebruik verder meestal Komodo als IDE voor XSLT, vind dat prima werken (gebruik het ook voor PHP en Python, vind het wel een prettig stukje software, als Pro-versie zelfs met SVN-integratie).

[Config]

Verwijderd schreef op maandag 14 augustus 2006 @ 16:31:
[...]


Met een HTML parser kunnen ze die data toch wel uit je webapp halen, ookal kost het ze een half uurtje meer. Security by obscurity werkt niet.

Natuurlijk werkt dat wel. Natuurlijk niet 100%, maar zodra alle grote websites aan dit soort systemen zouden hangen zou het 'afkijken' van data wel enorm toenemen. Het kleine webloggers moeilijk maken om dingen te kopieren van grote weblogs (ik noem maar een zijstraat) is een goede methode om misbruik tegen te gaan. Dat er dan ergens iemand is die het met veel moeite wel lukt, ach...er zijn ook bolletjesslikkers die het halen...

[...]


Attributen zijn helemaal niet lame, ze voorkomen gewoon dat je lamme <, > en / toetsen (en vingers) krijgt. Wanneer je ze moet gebruiken is idd niet altijd even duidelijk gedefineerd, maar meestal helpt CommonSense[tm] een hoop. Gewoon attributen gebruiken, tenzij het niet mooi lijkt in je document (door teveel attributen bij een tag, free-form parameters in attributen, etc).


[...]


Macht kwijt op de client? Je kunt nog steeds kiezen precies wat voor model data je rondstuurt als XML hoor... Ook HTTP responses zijn nog steeds voor jou om te beinvloeden. Verschillende browsers die het anders parsen is een issue, maar de drie groten (MSHTML, Gecko en KHTML) implementeren het allemaal goed. Ook zijn er meerdere tools om de XSLT serverside te processen indien de client een AGENT is die geen XSLT support (lynx, googlebot, etc). Je hebt dus off-loading naar de client en een fallback.

Fallback = dubbel werk? Zou je moeten meenemen in je overweging.

[...]


Sorry, maar ik vind dit uitermate kort door de bocht.

XML is helemaal niet slechts ontworpen om 'systemen te laten samenwerken'. XML is ontworpen om een standaard manier te hebben om data te formatteren, zodat zaken als transformaties bijvoorbeeld mogelijk zijn met een enkel tooltje ipv vierhonderd voor elk formaat data.

Oftewel: beter laten samenwerken (transformatie is een vorm van samenwerken)

Die 'dubbele verwerking' is trouwens niet iets wat je app veel slomer gaat maken, omdat browsers (zoals hierboven beschreven) het veelal zelf handlen. Ook helpt het je bandbreedte te besparen, omdat browsers de XSLT sheet cachen, waardoor dus _alleen_ nieuwe model data over het netwerk wordt gestuurd. Ook serverside processen is heel erg snel: XSLT is vooral een beschrijvende taal. Het enige wat het ding doet is wat output combineren.

XSLT biedt ook gewoon een hele mooie abstractie van de View. Kwestie van een andere XSLT sheet eroverheen en je kunt bijvoorbeeld zonder moeite PDF's bouwen van je documenten.

Ja het is een erg netjes systeem, mits je meerdere output formats nodig hebt. Anders is het slechts overhead.

[djc]

Config schreef op maandag 14 augustus 2006 @ 16:44:
Ja het is een erg netjes systeem, mits je meerdere output formats nodig hebt. Anders is het slechts overhead.

Jouw argument is dus YAGNI, maar in mijn geval bevalt het prima om van het tegengestelde uit te gaan.

[Verwijderd]

Config schreef op maandag 14 augustus 2006 @ 16:44:
Natuurlijk werkt dat wel. Natuurlijk niet 100%, maar zodra alle grote websites aan dit soort systemen zouden hangen zou het 'afkijken' van data wel enorm toenemen. Het kleine webloggers moeilijk maken om dingen te kopieren van grote weblogs (ik noem maar een zijstraat) is een goede methode om misbruik tegen te gaan. Dat er dan ergens iemand is die het met veel moeite wel lukt, ach...er zijn ook bolletjesslikkers die het halen...

Een half uurtje is niet veel werk of moeite. Er bestaan prima tools, zoals curl, om dat heel erg snel te doen. Het feit dat je eventjes wat HTML tags uit de input moet knippen gaat echt niet helpen als data-bescherming.

Zodra iemand zich intereseert in jouw data gaat het worden geextract. Dat is een simpele fact of life.

Fallback = dubbel werk? Zou je moeten meenemen in je overweging.

Nah, bestaan genoeg libs voor. Je kunt het zelfs helemaal in apache doen, maar een simpele 'if useragent does not support XSLT, process serverside" voldoet. Het is al in al misschien 10 regels code om dat te regelen.

Oftewel: beter laten samenwerken (transformatie is een vorm van samenwerken)

Transformatie is een vorm van data-manipulatie. Je kunt het zien als een vorm van samenwerken, maar dan wel met een hele andere definitie van samenwerken dan degene die je gebruikte in je originele post.

Ja het is een erg netjes systeem, mits je meerdere output formats nodig hebt. Anders is het slechts overhead.

Perhaps, mijn ervaring is vooral dat je de toekomst niet kunt voorspellen. Als het designen van iets op deze manier geen gigantische nadelen qua tijd/processing power heeft, dan is de gewonnen flexibiliteit mooi meegenomen, nietwaar? Wellicht wil je klant uiteindelijk wel PDF's, of moet er een hack ingebouwd worden voor een crappy browser of gaat de backend anders. Allemaal zaken waarbij XSLT je een hele hoop tijd bespaart. Software designen is niet alleen precies doen wat de klant wil, maar ook anticiperen wat de klant later nog van je zou kunnen willen. Aka, don't develop what they want, develop what they need.

[prototype]

Config schreef op maandag 14 augustus 2006 @ 15:25:
XML attributen zijn lame imo, ik zou alles tags maken. Wel zo helder.

XML attributen kan je ook vermijden op andere gronden dan 'smaak'. Een reden waarom ik zelf attributes vermijd is omdat attributes opzichzelf geen childs kunnen hebben, en omwille van flexibiliteit met het oog voor de toekomst kies ik dan voor tags.

[Config]

prototype schreef op maandag 14 augustus 2006 @ 17:24:
[...]


XML attributen kan je ook vermijden op andere gronden dan 'smaak'. Een reden waarom ik zelf attributes vermijd is omdat attributes opzichzelf geen childs kunnen hebben, en omwille van flexibiliteit met het oog voor de toekomst kies ik dan voor tags.

en bijvoorbeeld omdat je ook gewoon SELECT * wilt kunnen doen op een table, en daar dan elke kolom uit wil trekken, ongeacht hoeveel het er zijn of wat er in staat. Automatisering dus zonder dat je voor elk data object een eigen XML design hoeft te maken.

[Johnny]

prototype schreef op maandag 14 augustus 2006 @ 17:24:
[...]


XML attributen kan je ook vermijden op andere gronden dan 'smaak'. Een reden waarom ik zelf attributes vermijd is omdat attributes opzichzelf geen childs kunnen hebben, en omwille van flexibiliteit met het oog voor de toekomst kies ik dan voor tags.

Waarom zou je dingen zoals titel, url, of getal of een boolean ooit een child willen geven?

[prototype]

Johnny schreef op maandag 14 augustus 2006 @ 22:21:
[...]


Waarom zou je dingen zoals titel, url, of getal of een boolean ooit een child willen geven?

Analoog zou ik je kunnen vragen waarom je hier bij voorbaat geen rekening mee zou willen houden. Het is nogal kort door de bocht om te stellen dat iets niet een child nodig zou kunnen hebben in de toekomst, dat is geheel afhankelijk van de situatie tegen die tijd en juist daarmee hou je zodoende rekening ermee... zoals ik dus al zei.

[hamsteg]

prototype schreef op maandag 14 augustus 2006 @ 22:37:Analoog zou ik je kunnen vragen waarom je hier bij voorbaat geen rekening mee zou willen houden.

Ik zit nu meer als tien jaar professioneel in software te kloten en zowel ik, als mijn omgevingen, komen steeds vaker terug op die generieke oplossingen, re-usability, middleware layers,voor toekomstig gebruik etc.. De ervaring (gelukkig ook reeds ondersteund door onderzoeken en ervaringen) geeft aan dat je door dit soort doelstellingen soms ingewikkelde constructies bedenkt die vaak door achterhaalde technieken, hardware, software updates of what-ever bij een volgend project niet meer gebruikt worden en dus verloren tijd zijn geweest en extra fouten hebben geïntroduceerd.

Ik ben geen tegenstander van "reusability" of "voorbereid zijn op" maar dan moet er wel een concrete invulling zijn van de toekomst en de technieken (beleidsuitspraak: komende twee jaar doen we dit met technieken x, y, z). Bijvoorbaat ergens rekening mee houden omdat we het misschien gaan gebruiken is mij te vaag en beperkt mij in mijn huidige doelstellingen van het project, kost tijd en grote kans dat er weer een project faalt (iets wat in de IT juist door dit soort argumenten meer regel als uitzondering is).

Als je tegenwoordig voor web-communicatie echter met alles rekening moet houden (JAVA, XML, XLST, PHP, .NET, SQL, MySQL 4 of 5, AJAX, CSS1+2 ...) dan is mijn advies kijk naar wat er nu ligt en kijk over een jaar weer gezond opnieuw (hou jezelf wel op de hoogte van nieuwe technieken). Breng content zoveel mogelijk plain text onder in dBases en leef je voor de rest gewoon lekker uit op de huidige technieken, leer en weer critisch bij een volgende implementatie.

Als ik kijk hoe drie jaar geleden een website werd gemaakt en nu had ik dat nooit kunnen voorzien en had ik het mezelf alleen maar moeilijk gemaakt door te anticiperen op de mogelijke toekomst.