INaLCO - M2 Traductique
Cours XML 2010-2011
Réflexions à l'occasion du contrôle sur machine du 15 février 2011
- Question de méthode : lire le texte HTML
- <xsl:value-of> ou <xsl:apply-templates>
?
- Attention au jeu subtil des règles par défaut
- Principe
- Exemple 1
- Exemple 2
Le texte complet de l'exercice
- La solution proposée
-
Question de méthode : lire le texte HTML
- Quand on écrit une transformation XSLT, on spécifie le texte
HTML
qu'elle doit produire.
Ce texte doit donc être connu en tant que texte, et pas seulement par
l'image que donne le navigateur
(car des textes différents peuvent se visualiser de manière
prequ'identique).
C'est pourquoi je vous ai recommandé d'aller lire le texte source de l'exemple-type.
- Lors des essais, il est utile de contrôler que c'est bien le
texte
voulu qui est effectivement produit :
pour ce faire, rien ne remplace la lecture de ce texte, qui
exige que la feuille de style soit mise en œuvre
en ligne de commande avec xsltproc, et non pas
via la "processing instruction" placée dans le fichier XML
<?xml-stylesheet type="text/xsl" href="maFeuilleDeStyle.xsl"?>
- Se fier à l'interprétation que donne le navigateur présente
en effet un risque
considérable,
car un navigateur est toujours très laxiste : il accepte à peu près
n'importe quoi qui ressemble à du HTML.
Il est donc mal qualifié pour garantir la conformité du texte produit
par votre transformation !
- Bien sûr, l'utilisation de
xsltproc suppose
qu'on travaille sous Linux et non sous Windows,
et il est moins amusant d'aller lire le fichier engendré avec un
éditeur de texte
que de regarder l'image produite par le navigateur !
Mais c'est beaucoup plus efficace...
- En outre, cela vous permet de contrôler votre HTML en faisant appel au
validateur du W3C.
Pour cela, il faut assurer que votre transformation installe les informations nécessaires
dans l'en-tête du fichier produit.
C'est l'affaire de xsl:output, par exemple, pour du XHTML strict :
<xsl:output method="xml" indent="yes" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"/>
-
<xsl:value-of> ou <xsl:apply-templates>
?
Nous avons déjà parlé de ce dilemme en cours.
La règle initiale de la feuille de style que je vous propose en donne
une bonne illustration :
<xsl:template match="/">
<html>
<head>
<meta
http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Visualisation de <xsl:value-of select="poema/@titulo"
/></title>
</head>
<body>
<h4><xsl:value-of
select="poema/@autor" /> -
<xsl:value-of select="poema/obra/text()" />
(<xsl:value-of select="poema/obra/@fecha" />)</h4>
<div
align="center"><h3><i><xsl:value-of
select="poema/@titulo" /></i></h3></div>
<ol>
<xsl:apply-templates select="poema/estrofa" />
</ol>
</body>
</html>
</xsl:template>
- On emploie
<xsl:value-of> pour insérer
- une chaîne de caractères qui est
- unique (ou absente du document, auquel cas on insèrera la
chaîne vide : cas de
titulo optionnel)
et <xsl:apply-templates> dans tous les autres cas,
c'est-à dire
- lorsque on doit insérer une structure à construire et non
une simple chaîne
(cas du <xsl:apply-templates select="poema/estrofa" />
ci-dessus)
- ou que, s'agissant d'une simple chaîne, l'insertion doit
se répéter en fonction du contenu du document traité
(cas de la règle <xsl:template match="estrofa">
:
si on écrit <xsl:value-of select="verso" />, seul
le premier vers de chaque strophe sera produit).
- L'attribut
select obligatoire de <xsl:value-of>
détermine exactement son objet,
en ayant présent à l'esprit que l'expression XPath valeur de select
est évaluée dans le contexte de l'application de la règle.
Dans la règle initiale, le contexte est celui des fils directs de la
racine, à savoir l'élément unique poema.
On écrit donc sans ambiguïté select="poema/@autor", etc,
sans qu'il soit utile (ni nuisible) de préciser '/poema'
ou '//poema'.
- Dans
<xsl:apply-templates> l'attribut select
est optionnel : quand faut-il l'employer ?
Ne pas l'écrire est équivalent à écrire 'select="*"',
c'est-à-dire traiter tous les fils du sommet courant.
L'interprète XSLT va donc appliquer aux fils en question toutes les
règles à sa disposition, y compris les règles par défaut.
-
Attention au jeu subtil des règles par défaut
-
Principe
Les explications données dans les notes de cours ne sont peut-être pas
suffisamment éclairantes...
L'idée des règles par défaut, ou règles implicites (en anglais "default
rules") est d'éviter au rédacteur de spécifier ce qui va de soi.
Le tout est de s'entendre
- sur ce qui va de soi
- sur la manière de dire ce qui ne va pas de soi.
Traitons d'abord le second point, dont voici le principe :
Si au cours du calcul
- un sommet de l'arbre doit être traité,
- et qu'aucune règle écrite ne lui soit applicable,
- alors les règles implicites lui sont appliquées.
Il y a donc deux manières d'empêcher l'action des règles implicites sur
un sommet donné :
- en évitant qu'il doive être traité,
grâce à un attribut select judicieux dans les <xsl:apply-templates> qui pourraient vouloir s'intéresser à lui
- en écrivant une règle explicite adaptée à son cas.
Voyons à présent "ce qui va de soi", les règles implicites. Il y en a 3 :
- Traiter la racine ;
- Traiter tous les fils du sommet considéré, c'est-à-dire
<xsl:apply-templates
/> ;
- Envoyer en sortie le contenu textuel du sommet considéré
:
<xsl:value-of select="text()" /> .
Par conséquent, si on ne lui dit rien, le système effectue un parcours complet de
l'arbre du document,
en collectionnant les contenus textuels.
-
Exemple 1
Si dans la règle initiale on écrit <xsl:apply-templates
/> sans le select="poema/estrofa",
- le seul fils de la racine est
poema, et
comme aucune règle n'est définie pour lui dans la feuille de style,
les règles par défaut entrent en action, et on passe aux fils de poema,
à savoir les strophes et la balise <obra>.
- les règles de la feuille de style concernant
estrofa
s'appliquent à toutes les strophes en séquence
(leur présence inhibant le règles par défaut)
- et en l'absence de règle écrite pour elle, la règle
par défaut n° 3 s'applique à
<obra> !
ce qui produit le contenu textuel de cette balise, qui n'était pas
souhaité dans le cahier des charges.
D'où l'utilité de select="poema/estrofa" que l'on doit
lire : ne traiter que les strophes, et pas <obra>.
Notez que select="poema" serait inopérant puisque
conduisant au même comportement que 'select="*"'.
-
Exemple 2
En revanche, dans les règles "estrofa", inutile
(mais non nuisible) de
préciser <xsl:apply-templates select="verso" />,
puisque il n'y a que des vers et qu'on veut les traiter en séquence.
Compte-tenu des règles par défaut, on peut s'interroger sur l'utilité
d'une règle explicite <xsl:template match="verso">.
Si on supprime cette règle, la règle par défaut n° 3 va envoyer le contenu en sortie, mais sans l'encadrer entre <dd> et </dd>,
contrairement au cahier des charges. On a donc bien besoin d'écrire la règle <xsl:template match="verso">.
Pour une raison analogue, la règle par défaut n° 2 est insuffisante pour traiter les strophes, vu l'encadrement requis
entre <li><dl> et </dl></li>.