Une architecture web-XML

Ce site internet a été entièrement conçu à partir de documents XML, XSL et CSS.
Il
ne contient aucun fichier HTML, au sens traditionnel du terme.
Le principe est le suivant : les données (mon CV, ma liste de projets professionnels, etc.)
sont enregistrées dans un fichier XML, que des processus
XSLT transforment en page web, ou en document PDF, RTF...
Si des modifications doivent être apportées à mon CV, je modifie uniquement le fichier XML, et toutes les sorties, web comme papier, reflètent
instantanément, et automatiquement, ces modifications.
L'idée semble naturelle, et pourtant il a fallu des années d'évolution des navigateurs et des langages de programmation Internet pour que ce modèle devienne techniquement possible.
Pourquoi a-t-il fallu attendre si longtemps ?
D'abord parce que cette technologie repose sur une transformation du XML, une opération pas si simple en soi, réalisée grâce à un
parser.
Or, les navigateurs ne disposent pas tous d'un tel parser ; de plus, le fonctionnement des parsers peut encore différer d'un browser à l'autre.
On préfère donc réaliser cette opération de transformation en amont, sur le serveur d'hébergement lui-même.
Mais encore faut-il qu'un parser y ait été installé... Et ce n'est que depuis la version 5 que PHP en inclue un par défaut.
Auparavant, il fallait recourir à l'installation d'une librairie externe (Sablotron) - une opération système que j'ai eu à
réaliser plusieurs fois d'ailleurs.
C'est également une question de mentalité. Pour un webmaster, HTML et PHP sont plus abordables, plus faciles d'approche qu'XSL, langage de transformation abstrait, récursif et d'essence non procédurale.
Les technologies XML sont pourtant très efficaces, surtout sur le long terme :
- Modèle de données et présentation sont séparées, ce qui facilite considérablement la maintenance d'un site Internet, et la réutilisation des données sous d'autres formes
- On peut définir des structures de données arborescentes, riches et complexes (c'est tout l'avantage d'un document XML par rapport à une table SQL)
- La modularité est totale : un document XSL peut faire appel à d'autres documents XSL, et il est ainsi possible de créer des librairies de templates XSL
- Un élément défini au niveau présentation (dans le fichier XSL ou CSS) peut facilement être passé au niveau donnée (dans le fichier XML), si nécessaire : il suffit de repenser le modèle de données
- XML et XSL sont très stricts du point de vue de la syntaxe : les bugs sont donc rapidement repérés
- L'environnement technique requis est léger : il suffit d'un bon parser XSLT
Du XSL et du DOM au menu
XSL n'est pas le seul moyen pour exploiter un document XML.
On peut le remplacer par un script (écrit dans un langage web traditionnel) qui extrait du document XML les éléments nécessaires
à la construction de la page web. C'est une technique fréquemment utilisée avec ASP.NET ou J2EE par exemple. Ces environnements contiennent en effet
une implémentation d'un modèle standard appelé DOM, dont les classes permettent d'explorer un document XML, en balayant
sa structure grâce au langage de requêtage XPath (d'ailleurs également utilisé avec XSLT).
Par rapport à XSL, cette façon de procéder s'avère utile surtout si des opérations spéciales (connexion avec une base SQL, exécution de
programmes externes, etc.) ou des calculs complexes,
doivent être menés avec les données, et que seuls un langage de programmation classique, dans son framework, sera à même de réaliser.
Cependant, avec le développement des web services, qui reposent sur une syntaxe XML, et l'introduction de fonctionnalités d'import/export
XML dans un nombre
toujours plus grand d'applications, on peut penser que le recours à un langage de script traditionnel sera de moins en moins nécessaire sur le web.
Petite anecdote en passant : en 2006, j'ai eu l'occasion de développer avec le logiciel Envox, qui sert à programmer des serveurs vocaux téléphoniques (du genre de ceux qui vous accueillent sur les hotlines), bref, un milieu bien différent du web. La programmation se fait à la souris, en tirant des liens entre des petites boîtes, au sein d'une belle interface graphique. Or il se trouve que même ces scripts téléphoniques réalisés avec le logiciel Envox sont enregistrés au format XML.
et CSS dans tout ça ?
Le site Internet que vous consultez actuellement repose aussi sur CSS2,
un système astucieux qui permet de définir et redéfinir
ses styles de présentation à volonté, auxquels le code HTML des pages fait référence.
Aujourd'hui, pour monter une page web, il n'est donc plus nécessaire d'avoir recours à l'imbrication invraisemblable de tableaux HTML
et de pixels invisibles (qui servaient à faire "tenir" les tableaux) comme cela se pratiquait encore dans les agences web il y a quelques
années (et comme j'ai eu à le faire souvent !).
La généralisation de CSS comme technique globale de montage des pages n'est possible que depuis la disparition des "vieux navigateurs" (tel Netscape 4),
l'amélioration d'IE, et l'émergence de Mozilla/Firefox, un browser qui colle de très près aux standards du web.
CSS n'est d'ailleurs pas sans lien avec XML : d'abord parce que c'est le consortium W3C qui en assure la direction, comme pour XML et XSL. Ensuite parce que ce système tend à séparer le contenu de la forme : en gros, vous placez vos données dans des balises DIV (des conteneurs), et vous précisez dans votre fichier CSS où dans l'écran, et de quelle manière, vos données vont s'afficher.
Corollaire : pourquoi ne pas afficher alors un document XML avec une simple feuille CSS ? Cela se pratique déjà, mais cela n'est envisageable que si la structure XML des données reste simple et linéaire, autrement, si le gabarit de la page est un peu complexe, il faut avoir recours à XSL, ou au DOM.
XHTML et le web sémantique
Vu que leurs effets visuels peuvent se redéfinir entièrement avec une feuille de style,
les balises HTML deviennent presque interchangeables, au point que l'on peut se demander si l'on a encore besoin de HTML... D'ailleurs, avec le
standard XHTML, la tendance est à la restriction du vocabulaire utilisable.
En fait, derrière cet appauvrissement, fort éloigné de ce qui se passait à la fin des années 90 (époque marquée par une guerre sauvage
entre browsers, qui rivalisaient d'innovations techniques et de balises toujours plus puissantes), l'idée est d'inciter
les webmasters à utiliser les balises pour leur sens, et non plus pour leur
effet visuel. Ainsi, en XHTML Strict, l'usage de la traditionnelle balise <u>, qui en HTML standard sert à souligner un mot, est-il déprécié,
car le nom même de cette balise (u comme underline) renvoie à une caractéristique graphique, et non sémantique.
A contrario, prenons l'exemple de la balise <blockquote>, présente en HTML standard comme en XHTML. <blockquote> introduit normalement une citation (d'un auteur par exemple).
La manière
dont cette citation est rendue (par une indentation, une diminution de la taille de la police, le passage en italique...) se règle
dans le fichier CSS, et les navigateurs disposent d'ailleurs de paramétrages par défaut (généralement, une indentation de 40 pixels)
pour le cas où le webmaster n'aurait rien prévu dans son fichier CSS.
Or une balise <div> pourrait tout aussi bien faire l'affaire, vu que son comportement peut se paramétrer de la même façon en CSS.
Mais il est intéressant d'utiliser la balise <blockquote> pour faire une citation, même si, visuellement, il ne ressort pas de
différence notable pour l'utilisateur, par rapport à un <div> similairement paramétré :
D'abord parce que du point de vue de la maintenance, il devient ainsi possible de personnaliser
le rendu en fonction du media de sortie (par exemple, les citations seront
rendues en italique pour la version imprimable, et en police normale pour la version web).
Ensuite, on facilite l'exploitation : il sera ainsi possible de répondre à des requêtes du type :
donne moi toutes les citations présentes dans cette page (ou dans ce site).
Ce faisant, on aide également les moteurs de recherche, robots d'indexation et autres agrégateurs de contenu
à comprendre qu'il s'agit d'une citation.
Or le web tend à être exploité de plus en plus par des machines, de façon automatique, et plus seulement par des êtres humains avec
un navigateur. Pour que ces machines interprètent correctement ce qu'elles lisent, il faut leur
parler avec un vocabulaire précis, faisant référence à des concepts connus.
Bref, sur le web aujourd'hui, la tendance est à structurer le contenu des pages en fonction du sens, et non plus en fonction du rendu visuel souhaité à un moment donné. C'est une évolution importante vers ce que les spécialistes appellent le web sémantique.
+33 (0)6.84.49.85.48
