Cours XML et feuilles de style

Cours XML et feuilles de style, tutoriel & guide de travaux pratiques en pdf.

XML et feuilles de style

Ces clarifications apportées, il reste qu’un fichier XML n’est pas, en général, un fichier affichable/présentable en l’état. Il faut donc lui ajouter quelque chose pour que cet affichage soit possible. Ce quelque chose a été appelé « feuille de style », par une analogie un peu boiteuse avec les feuilles de styles stricto sensu — comme les feuilles de style CSS ou les styles de MS Word — qui servent à associer (de manière centralisée) des caractéristiques typographiques (marges, alignements, polices et tailles de caractères, couleurs, etc.) à un contenu déjà orienté-présentation.
En XML une feuille de style stricto sensu n’est bien entendu pas suffisante. Si votre XML contient, par exemple, une bibliographie, vous pouvez certes l’associer directement à un feuille de style CSS qui vous permettra, par exemple, d’associer à l’élément auteur la police Verdana 14 points et la couleur teal. Mais une telle feuiIle de style CSS ne vous permettra pas de spécifier :
• que vous voulez que la bibliographie soit présentée sous la forme d’un tableau, ou sous la forme d’une liste ;
• qu’elle doit être classée selon tel ou tel critère ;
• que les différentes informations relatives à un même livre (auteur, titre, éditeur…) devront apparaître dans tel ou tel ordre, avec tels ou tels séparateurs, etc.
On voir par cet exemple que pour qu’un fichier XML puisse être affiché de manière réellement intéressante, il nous faut pouvoir spécifier :
• non seulement les objets de présentation génériques, tels que listes et tableau — et à l’intérieur de ceux-ci l’italique, les sauts de ligne, etc — qui vont être mis en oeuvre pour afficher son contenu ;
• mais encore, et surtout, la façon dont les parties constitutives du contenu (en l’occurence les livres et à l’intérieur de ceux-ci les auteurs, les titres etc.) vont être distribuées à l’intérieur de ces objets génériques — dans quel ordre, selon quel classement, etc.
Dans le premier cas on parlera d’objets de formattage ou formatting-objects. Et nous constatons qu’HTML (ou plutôt le couple HTML + CSS) nous fournit d’ores et déjà de tels objets de formattage, à peu près suffisants tout au moins pour l’affichage sur écran.
Dans le second cas on parlera de transformation.
Cette analogie boiteuse qui avait été faite au départ avec les feuilles de styles stricto sensu explique que dans les premiers projets de spécification du W3C le langage de transformation propre à XML que nous appelons aujourd’hui XSLT a pu être mélangé, dans un projet des spécification unique baptisé à l’époque XSL (Extensible Style Language), à un tout autre langage. Cet autre langage étant, lui, destiné à définir des objets de formattage plus riches que ceux de HTML puisque destinés à de présenter un contenu XML sur les supports les plus variés (écran, mais aussi papier…)
Désormais les choses sont beaucoup plus claires, puisque les deux langages ont été séparés. L’un est devenu XSL Transformations (XSLT) et l’autre XSL-Formatting Objects (XSL-FO). Le premier seul est à l’heure actuelle arrivé au stade de spécification du W3C.

L’espace de nom (namespace) de XSL(T)

XSLT constitue un bel exemple d’utilisation de la philosophie des « espaces de nom » XML (XML namespaces). Toute feuille de style XSL(T) débute en effet (après la processing instruction xml) par une déclaration de l’espace de nom xsl :ou (synonyme)
Deux avantages :
• Le préfixe xsl: va permettre de différentier à l’intérieur de la feuille de style les éléments qui appartiennent au langage XSLT de ceux qui devront apparaître dans le résultat final (les « éléments de résultat litéral »)
• L’URI spécifiée dans la déclaration de l’espace de nom va éventuellement permettre de distinguer plusieurs implémentations de XSLT. (C’est ce que fait en particulier le nouveau moteur XSLT (MSXML3) de Microsoft et qui lui permet de traiter aussi bien des feuilles de style « IE5 natif » que XSLT 1.0)
Note. Le préfixe xsl: est le préfixe couramment utilisé mais n’est pas obligatoire. L’important est l’URI spécifiée dans sa déclaration.

La philosophie des « règles modèle » (templates)

Qu’est-ce qu’une règle modèle (template)?

Comparaison avec les règles CSS
En dépit de ce qui vient d’être dit sur la différence entre CSS et XSLT, il est utile de partir de l’exemple des feuilles de style CSS pour bien comprendre comment fonctionnent les règles modèles XSLT.
On se rappelle qu’une feuille de style CSS se compose d’un certain nombre de règles (rules). Chacune de ces règles se composant :
1. d’un sélecteur (ex. p.commentaire em, qui signifie « les balises contenues dans une balise
de classe commentaire »)
2. d’une ensemble de déclarations du type propriété (ex. color) – valeur (ex. yellow)
p.commentaire em {
color: yellow
}
L’effet d’une règle CSS est que si un élément (une balise) du source HTML se trouve satisfaire à la condition exprimée par le sélecteur de cette règle, l’objet de formattage correspondant (paragraphe pour une balise
, cellule de table pour une balise, etc.) se verra affecté des caractéristiques spécifiées par les déclarations de la règle (dans notre exemple la couleur jaune).
Mais il est important de comprendre qu’une feuille CSS ne fait que décorer un arbre HTML ; elle ne le modifie pas. Une règle CSS ne fait qu’ajouter des caractéristiques nouvelles (positionnement, couleurs, polices de caractères, etc.) à un objet de formattage qui aurait été généré de toutes façons, CSS ou pas. En conséquence une régle CSS vide (ne contenant aucune déclaration) sera simplement sans effet : lorsqu’une balise satisfera aux conditions exprimées par son sélecteur, l’objet de formattage associé sera généré exactement comme si la règle n’existait pas.