Pourquoi baliser et comment

Tout le monde a déjà vu des pages Web ¹. 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. J’ai adopté le TEI XML pour tous mes gros projets et je ne pourrais plus travailler autrement

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 :

• Le but du balisage peut être prioritairement d’ouvrir la possibilité d’étudier, d’analyser le texte par des moyens informatiques. C’est le cas de la Text Encoding Initiative (TEI) créée par des philologues et des linguistes et dont les origines remontent à 1987², avant le Web (1989-1990) et bien avant le XML (1998). (On appelle digital humanities des études littéraires qui s’aident de l’informatique.) La TEI est devenue un consortium de nombreuses universités, bibliothèques et autres institutions.

• Le but du balisage peut être de faciliter et de systématiser la publication. C’est le cas de DocBook et de DITA (Darwin Information Typing Architecture, venant d’IBM — rien à voir avec Dita von Teese) qui sont spécialisés dans l’édition de documentation informatique et dans les systèmes d’aide en informatique. Dans cet objectif, on peut distinguer encore divers aspects :

  • Séparer de sa publication l’élaboration et l’enregistrement du contenu. À partir d’un même contenu balisé, on peut tirer automatiquement des sorties différentes, comme le système d’aide incorporé à un logiciel, un site Web (un ensemble de pages HTML), un livre digital (souvent au format EPUB) ou un livre à imprimer sur papier (un fichier PDF ou autre). L’avantage est énorme. Une fois qu’on a fait dans les transformations automatiques un certain nombre de choix, divers contenus seront transformés avec peu de travail dans les différents formats de sortie avec une grande unité de présentation et des modifications apportées au contenu de départ peuvent être automatiquement répercutées dans les divers formats de sortie sans qu’il soit nécessaire de modifier chacun d’entre eux.

  • Systématiser et faciliter la structuration du contenu (et par conséquent sa présentation) en proposant à l’auteur un cadre structurant.

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 :

• Le texte est balisé du point de vue fonctionnel en XML (TEI, DocBook…). Cette version unique (que je serais tenté d’appeler « matrice », mais ce n’est pas une appellation consacrée ; j’ai rencontré master en anglais) sert de base à toutes les autres. Elle seule est maintenue.

• La forme document d’un seul tenant (comme un livre) n’est pas un absolu. Tous les documents XML (y compris TEI) peuvent être fractionnés avec XInclude, quitte à les recombiner avant les traitements qui ne géreraient pas ce fractionnement. Ce qui compte c’est l’idée d’encoder sémantiquement une source unique (qu’elle soit d’un seul tenant ou pas ³) pour en tirer différentes présentations.

• Des transformations (XLST) sont appliquées à cette version de base pour obtenir des formes lisibles à afficher ou à imprimer (HTML, PDF…). En particulier en HTML, on peut obtenir automatiquement le découpage par chapitre ou autre niveau avec tables des matières entière ou partielles et liens de navigation entre les différentes pages.

• Si on doit corriger, on corrige seulement la matrice et on applique de nouveau la transformation pour obtenir les formes (HTML, PDF…) à jour (plutôt que de reporter la correction dans les différentes formes).

• À partir du balisage, on peut procéder à des recherches ou à des traitements, comme la production automatique d’un index des mots qu’on aurait marqués comme devant être indexés.

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.