Dominique Meeùs
Dernière modification le   
retour à la table des matières — à l’index — à ma page de départ

Balisage en XML
Pourquoi et comment baliser structurellement — la TEI et les autres

Je considère ici différentes techniques d’édition de texte structuré. Il s’agit de balisage au sens de markup, on marque le texte dans un langage de balises (tags). On pourrait dire que c’est un balisage fonctionnel, qui marque dans le texte les différents fonctions (structurelle, sémantique, syntaxique…). Qu’est-ce qui est une section du texte et qu’est-ce qui en est le titre ? Qu’est-ce qui est une citation, une référence bibliographique ? Qu’est-ce qui est un titre d’ouvrage. En contexte informatique, qu’est-ce qui est un exemple de code, le nom d’une fonction, la valeur d’une variable, qu’est-ce qui est un message d’erreur ? On balise ces fonctions en les séparant le plus possible de leur présentation : on balisera par exemple l’emphase (l’intention de l’auteur d’insister) plutôt que l’usage d’italiques au niveau visuel.

Tout le monde a déjà vu des pages Web 2. Certains savent qu’elles sont obtenues en balisant du texte dans un système de balises (tags) dit HTML ou dans sa variante XML qu’est le XHTML. Ce que je vise ici ce sont des formes de balisage en XML où les aspects fonctionnels sont plus rigoureusement encore séparés de la présentation et où on peut baliser des choses qui n’ont rien à voir avec la présentation. C’est nettement moins connu encore que le HTML, en dehors des spécialistes, mais ça me semble très important et j’ai trouvé ça très utile.

En particulier, la rigueur du XMl ajoute plus de possibilité de traitement automatique, de transformations, de réutilisation et récupération, et donc aussi de pérennité des données.

Cela recouvre en fait plusieurs objectifs différents :

Ces divers objectifs peuvent être présents à divers degrés. La motivation de la TEI est la possibilité d’étude du texte, mais il existe des transformations, fournies par la TEI, qui permettent de publier dans divers formats de sortie le contenu balisé et, personnellement, je l’utilise pour publier sur le Web. Le format DocBook est très populaire en informatique ; c’est le format sous-jacent à de nombreuses pages d’aide sur le Web dans le logiciel libre (des manuels qui souvent s’appellent How To) et des livres d’informatique sont publiés à partir d’un contenu balisé en DocBook. DITA, moins répandu, insiste sur le « structured authoring » qui favorise une structuration standardisée, mais cet aspect est présent aussi dans DocBook et les TEI Guidelines prescrivent qu’on ne fasse pas n’importe quoi.

Un document TEI ou DocBook est pensé dans le mode linéaire et hiérarchique, arborescent d’un livre (mais on peut y faire des court-circuits hypertextes) et DITA se veut plus modulaire : on écrit de petits modules indépendants qui peuvent ensuite se combiner de diverses manières. Mais on peut avec XInclude fractionner tout travail en XML, donc aussi un projet TEI ou DocBook, en plusieurs fichiers (bien que ceux-ci ne constituent pas des modules comme en DITA).

Aux objectifs premiers exposés plus haut, il faut ajouter la pérennité. On peut avoir aujourd’hui de vieux fichiers de Word ou de Wordperfect sous DOS et on éprouve qu’il n’est pas simple de les ouvrir pour en récupérer le contenu. En écrivant aujourd’hui, il faut penser à ce problème pour l’avenir. Tout ce qui est écrit dans un dialecte XML pourra être sauvé ; le XML est assez riche et général pour durer longtemps ; si l’application particulière n’existe plus, on pourra au moins écrire en XSL des transformations pour en automatiser la récupération.

En fin de compte, j’ai choisi la TEI pour son ouverture, sa polyvalence. En l’utilisant seulement pour publier, je la détourne d’une certaine manière de son but premier ; encore que dans le cas de mon projet de notes de lecture, en confiant aux stylesheets de la TEI le soin de me produire automatiquement un index des notions que j’ai balisées comme devant être indexées, j’exploite un peu plus le côté analyse basée sur les balises, typique de la TEI. On pourrait écrire autre chose en DocBook que de l’informatique, mais la spécialisation informatique de DocBook et de DITA risque d’être un peu limitative (tandis que la TEI, infiniment plus riche et plus souple, permet aussi de marquer de l’informatique, même si c’est moins immédiat).

En TEI et en DocBook, une fois qu’on a balisé en XML son contenu et qu’on dispose des transformations écrites en XSL, on peut les exécuter simplement avec n’importe quel processeur XSLT. En DITA, il n’y a pas de salut en dehors de l’installation de tout le DITA Toolkit, une énorme usine à gaz en Java, c’est-à-dire un très élégant ensemble de nombreux programmes qui devraient se combiner merveilleusement, sauf qu’avec moi ça ne marche jamais out of the box et qu’on ne peut pas savoir pourquoi à moins d’être ingénieur Java. DITA semble donc réservé aux hackers plus doués que moi en Java ou aux entreprises assez riches pour avoir ce genre de compétence dans leurs services ou pour payer des consultants pour mettre en place la chaîne de production.

On pourrait citer d’autres systèmes d’encodage et de balisage : xdoc (pour la documentation et les fichiers d’aide de programmes, plus simple que DocBook), asciidoc (syntaxe très simple, un peu genre wiki, pouvant engendrer du DocBook), DTBook (avec préoccupation d’accessibilité text to speech pour les malvoyants)…

Je crois que si on a des textes d’une certaine ampleur à publier, qu’ils soient nouveaux ou repris avec un logiciel de reconnaissance de caractères, de livres que l’on trouve importants, il ne faut pas perdre son temps à les éditer en HTML ou en texte Open Document Format (pour éventuellement les enregistrer aussi en PDF) — ce serait une erreur, de mauvaise politique ; il faut investir dans la connaissance de la TEI et les encoder en TEI pour en tirer ensuite HTML, EPUB, texte ODF ou PDF au choix. Personnellement, j’ai beaucoup écrit en HTML et j’écris encore directement en XHTML quand je veux produire des pages web indépendantes, mais je passe maintenant à la TEI pour tout projet structuré d’une certaine ampleur et je récupère même en TEI des ensembles existants de pages Web, comme le présent projet de notes en informatique.

Il y a de très bons textes pour expliquer la supériorité de l’encodage structuré, qui expliqueront ça mieux que moi. (C’est un investissement supplémentaire ; il faut se convaincre que ça rapporte.) Voyez les textes sur la justification de DocBook ou de la TEI sur le site du TEI Consortium ou de DocBook.org ou en cherchant avec Google.

On peut tenter de concrétiser ce qui précède (du point de vue de la publication, qui est le mien) en décrivant la suite des opérations :

Un bémol, cependant : que l’on fractionne ou non son travail, il s’agit d’un travail qui a la structure hiérarchique d’un livre. On peut y faire des courts-circuits hypertextes. Pour un travail très hypertexte sans structure, comme pourraient l’être les pages d’un wiki, on pourrait préférer autre chose. Cependant, avec des divisions d’un seul niveau (une série d’articles) et des liens hypertexte entre elles, on a quelque chose qui y ressemble.

Notes
2
On peut encore en lire la première page, qui présente le projet du WorldWideWeb (W3).
3
Un inconvénient de l’usage d’XInclude, c’est qu’on ne sait plus où on a écrit quoi : dans les pages HTML dérivées, la navigation montre dans quelle division c’est, mais il est plus difficile de savoir dans quel fichier d’inclusion cette division se trouve. Quelques idées :
  • On peut évidemment toujours faire grep "quoi" *.xml dans le dossier où on range ses fichiers XML à inclure.

  • Je note en commentaire le nom de fichier d’inclusion sous la division qui en constitue la racine. Si je conserve le fichier TEI toutes inclusions résolues, je peux y rechercher un mot et voir dans quel fichier d’inclusion il intervient.

  • Important à savoir. Un élément <xi:include> ne peut avoir pour enfant qu’un unique élément <xi:fallback> et aucun autre du namespace XInclude. Tout autre élément de ce namespace entraîne une erreur fatale. Par contre, du texte en contenu n’est pas une erreur et est absolument ignoré dans le processus d’inclusion XInclude. (Sont ignorés de même des éléments étrangers à XInclude.) On peut donc y mettre le titre de la division à inclure, ou tout autre texte comme
    <xi:include href="inclusions/unedivision.xml">Titre de la division, avec son contenu en deux mots</xi:include>
    ce qui facilite la relecture du fichier TEI avant résolution des inclusions.
Dominique Meeùs . Date: 2011… 2016