Résumé
On définira ici quelques éléments d'un document structuré (divisions, blocs ...) afin de présenter et de comparer plusieurs schémas XML "généralistes" (dont HTML, Docbook et TEI), selon qu'on souhaite diffuser, encoder ou créer des documents électroniques.
Table des matières
Pour l'utilisateur habituel, le traitement de texte est souvent la référence en matière de texte numérique. Il est alors difficile de distinguer le format et la restitution de l'application productrice. D'ailleurs, rien n'y invite. Les applications sont commodes et très bien étudiées, tandis que l'encodage des informations est "binaire" (illisible par l'humain) et propriétaire (établi par l'éditeur d'une application). Les problèmes d'incompatibilité s'aplanissent (par victoire d'un monopole), cependant, il est très difficile de récupérer un contenu (et sa structuration), hors de l'application qui l'a produit. En général, ces documents sont destinés à l'impression qui se fait très bien. La publication Internet (contrôlée) est plus aléatoire. Le traitement automatique, comme l'indexation ou la transformation, devient très difficile sans utiliser une extension achetée au propriétaire.
La force du concept tient au "WYSIWIG" (What You See Is What You Get). Ce que je vois à l'écran, c'est ce qui va s'imprimer, c'est ce que j'aurai sur Internet. Très agréable pour l'utilisateur, cette transparence devient une limite pour représenter la structure. Le format de départ mélange toujours la présentation à la sémantique. Lorsqu'on renonce à cette transparence, par un petit pas d'abstraction on comprend que l'on aimerait avoir plus que ce que l'on voit. Ainsi, lorsque je mets un titre, peu m'importe qu'aujourd'hui il soit gras et grand, demain je peux le vouloir bleu, ou l'extraire pour une table des matières, ou une bibliographie.
La structuration du texte fut l'une des raisons à l'origine des "*ML". Il est question de définir des formats qui expliquent la nature des informations écrites, sans imposer de présentation. Les schémas (ou DTD) de documents structurés se sont ainsi employés à définir les éléments sémantiques qu'une communauté souhaite distinguer (phrase, bloc, liste, tableau, division, structure). Ces définitions peuvent être employées selon trois grandes orientations (nullement exclusives les unes des autres) : la diffusion , l'encodage, la rédaction.
La rédaction d'un schéma conduit à définir des règles, une sorte de grammaire. Il y a généralement un ordre logique d'exposition, permettant de limiter les seuils d'emboîtements. On met rarement toute une section en gras ; qui voudrait citer tout un livre dans un paragraphe ? Cette logique rédactionnelle est plus strictement définie en XML, arrêtant ce qui contient et ce qui est inclus.
Les éléments de niveau phrase (tels gras, italique ou souligné dans un paragraphe) sont contenus par un bloc . La proximité avec les processeurs de texte habituels (qui distinguent peu la structuration de la présentation) donne l'occasion de bien identifier la spécificité d'un balisage sémantique comme XML. Une citation est une distinction sémantique, pour laquelle l'italique n'est qu'un exemple de restitution. Préciser une couleur a peu d'intérêt dans une source documentaire susceptible de multiples présentations, à moins qu'il ne s'agisse d'une convention, auquel cas un élément sémantique est probablement nécessaire, tel <alert/>, <lien/>.
C'est souvent sur ce niveau qu'un schéma manifeste sa spécificité, en identifiant les sémantiques qui concernent son domaine d'origine. Pour de la documentation informatique on trouvera des <hardware/>, <mousebutton/>, <interface/> . Ils sont peu utilisés mais en HTML, mais on trouve ainsi <code/>, <samp/> (exemple de sortie d'un programme), <kbd/> (entrée au clavier), <var/> (variable). Dans d'autres on trouvera plutôt des noms pour encoder de la poésie (stances, vers, césures ...).
Cependant, un schéma documentaire complet se doit d'offrir l'outillage de balisage dans le texte pour distinguer entre autres : noms, dates, liens, citation bibliographique, notes de bas de page, mots indexés...
Les éléments de niveau bloc contiennent les phrases et entrent dans les sections. On y trouve essentiellement les paragraphes. Tableaux et listes ont un statut particulier, car il peuvent contenir des paragraphes, ainsi qu'eux-mêmes.
Dans le même sens que la réflexion sémantique sur les phrases, les blocs peuvent repérer des contenus remarquables, tel le résumé d'une section (<abstract/>) ou de quoi extraire un diaporama. On trouve moins de spécificité et de variété à ce niveau qu'au précédent, les blocs sont souvent des conteneurs assez neutres.
Une liste aligne une collection d'items de même nature. La rédaction numérique a diffusé cette manière d'écrire et de penser. Certains lui reprochent de rompre le flux de la parole (à l'image millénaire du texte à dire) mais cette structure a aussi ses vertus expressives. On distingue généralement les listes ordonnées :
I, II, III
A, B, C
IV.A.4.c
...
et les listes sans ordre
point
carré
flèche
Mais bien d'autres collections sont possibles. On trouve des listes de définitions (glossaires, dictionnaires), de questions/réponses (pour les Foires aux Questions, FAQ), les menus (comme pour une interface), les listes de liens... bibliographies, table des matières, chronologies, calendriers peuvent appartenir à cette dernière catégorie (rangement linéaire). L'aide à la rédaction de cette sorte de séquences (d'une touche, ajouter un item avec les champs obligatoires) est un gros intérêt des éditeurs XML spécialisés.
Les tableaux alignent des lignes et des colonnes. L'ordre tabulaire remonte à la pensée agraire (sillons parallèles, damiers), il fait encore toute la puissance d'une base de données relationnelle. On peut considérer que la grammaire de l'objet (les règles) est presque définitivement définie [Cals]. Il ne reste plus qu'à choisir un vocabulaire [HTML], [Docbook].
Une division est un ensemble de blocs identifiée par un titre, une division peut contenir des divisions (chapitres, articles, parties, livres, cahiers...). Manuscrits, imprimerie, le texte a une longue tradition de divisions, souvent issues de réalités matérielles (rouleaux, feuillets...). La tradition a laissé des habitudes, mais pas de normes strictes. Le choix s'effectue ainsi :
Les parties sont identifiées par un niveau de titre. N'autorisant pas l'inclusion hiérarchique récursive, les processeurs de textes habituels n'ont que deux niveaux de balisage, par styles de caractères ou de paragraphes <titre1/>, <titre2/>, <titre3/> .... Ce modèle est très limité, en particulier lorsqu'on souhaite que chaque section partage un même genre de déclarations (une date, un auteur ...).
Les parties sont encloses par un élément identifiant son niveau (<section1/>/<section2/>/<section3/>/..., ou <book/>/<chapter/>/<article/>/<part/>/...). Plus avancé que le modèle précédent, il manque encore de fluidité.
Imaginons que j'ai une collection de livres courts (<livre/>/<chapitre/>). Je veux en faire une édition sous forme de recueil. Or un recueil est aussi un <livre/>. Pour une recollection automatique, je dois renommer tous mes petits livres, pour qu'ils deviennent des chapitres (en répercutant sur toute la hiérarchie des divisions).
Un seul élément distingue les sections et les titres, le niveau se déduit par l'imbrication des éléments <section><titre>section 1</titre><section><titre>titre 1.1</titre></section></section>. Conceptuellement et techniquement, ce modèle est très satisfaisant. Il faut cependant s'assurer que les rédacteurs y adhèrent. Un universitaire l'utilise communément, par contre, un journaliste pourrait préférer des unités métier plus concrètes.
SGML (1970, ancêtre de XML, 1998) resta longtemps confidentiel, mais l'explosion d'Internet fit découvrir les chevrons (< >) au monde entier. Contrairement à l'intention initiale du format, développé dans le monde industriel pour sa documentation, le public l'aborda paradoxalement, comme une syntaxe de présentation, permettant de facilement écrire/générer des paragraphes, des listes, et surtout des liens. De fait, c'est devenu une référence pour de nombreux autres schémas, qui y puisent noms et syntaxes pour formuler leurs besoins.
HTML devient la DTD le plus répandue dans le monde. Il faut cependant rappeler à cet endroit qu'il se conforme à la norme SGML, des éléments peuvent rester ouverts, les attributs peuvent être sans guillemets. La version XML doit être nommée XHTML. Son succès repose sur des qualités, mais aussi des défauts.
Les qualités :
Des noms brefs, mnémotechniques, en nombre limité.
Documentation, logiciels, une quantité inégalée de ressources.
Un modèle de tableaux éprouvé.
Les inconvénients :
Structuration faible.
La diffusion a généralisé des habitudes de présentation très éloignées d'une structuration sémantique (ex: <table/>).
XHTML2 est un projet du [W3C] en cours d'officialisation (au titre de recommandation). Suite à l'énorme succès de HTML, il y a paradoxalement un moment propice à une refonte en profondeur, afin d'y mettre la structuration qui y faisait défaut (à l'exemple des DTDs généralistes). Ce vocabulaire semble suffisant pour des documents de la taille d'un article, de plus, il est promis à une définition modulaire. Conforme à la recommandation des espaces de noms, il se destine à être un conteneur pour d'autres schémas (MathML, SVG, XForms). Certains modules (tableaux, phrases...) peuvent aussi être importés pour, par exemple, baliser le texte riche d'un élément <description/>.
Le projet Apache (HTTPD serveur, Perl, Tomcat, Cocoon ...) propose une plate-forme de diffusion documentaire fondée sur un schéma volontairement simple, très inspiré par HTML. On y trouve des éléments très spécifiques de la documentation informatique, mais aussi un schéma d'articles. Cette solution n'est pas exemplaire, sauf lorsque l'on souhaite adopter les outils associés sans autres développements. Par contre, il exprime clairement les manques de HTML (sections, métadonnées).
Le nom n'inspire pas le sérieux, mais la chose est très intéressante. Un Wiki est un site web dynamique dont tout visiteur peut modifier les pages à volonté. Le nom provient de l'hawaïen "WikiWiki" qui signifie "vite". On pourrait objecter qu'une telle souplesse s'expose au vandalisme. En réalité, les rédacteurs/lecteurs sont généralement bien plus motivés que les destructeurs, et les pages s'enrichissent, se corrigent et se traduisent remarquablement vite, et sans coûts. Des exemples ? wikipedia, Docbook.
Le procédé est surtout utilisé pour répondre à un besoin récurrent de l'informatique libre : le manque de documentation. Les développeurs ont leurs procédures de travail collaboratif, évidemment très contrôlée pour que le logiciel continue à tourner après une modification. La documentation officielle se produit dans les mêmes conditions. Mais les développeurs n'étant ni rédacteurs, ni payés pour le faire, il y a des lacunes, des fonctions sont implantées avant d'être documentées.
Les forums et listes de diffusion ont longtemps joué ce rôle d'échange des compétences, mais dans un projet actif (plusieurs centaines de messages par jour), il devient rapidement impossible de retrouver la réponse à sa question. Donc, on la repose à la communauté, espérant qu'une bonne âme répondra, ou indiquera le bon lien, ce qui propage parfois des rumeurs quand aucun expert n'est en ligne.
Wiki remplit le besoin d'un site rédactionnel dynamique, entre le projet éditorial contrôlé d'une documentation, et l'amas peu lié de courriels. Cela demande un peu de balisage. Il n'y a pas exactement de syntaxe arrêtée, chaque installation peut définir ses règles. On isole cependant les besoins suivants :
Editable dans un champ texte
Transposable en HTML
Mnémotechnique
Pas de validation
Ce dernier point (pas de validation), explique pourquoi la forme choisie n'est pas XML (les rédacteurs pourraient oublier de fermer des balises). Cependant, le balisage caractères produit par les auteurs est généralement converti dans un XHTML simple, dont on transposera vite les noms en lisant une aide de rédaction.
Les milieux académiques se sont rapidement appropriés la norme industrielle SGML, en particulier pour un besoin important, l'encodage de textes existants (ex: Shakespeare). Numériser un livre, cela peut consister à en scanner les pages pour en conserver autant d'images. Cependant, le contenu (les mots) sont encore là difficilement exploitables, à moins que ces images passent par un logiciel de reconnaissance des caractères (OCR). A cette étape, le texte brut nécessite quelques corrections, de plus, il a perdu la plupart de sa structure, sinon la division des paragraphes et des pages. C'est à cet endroit qu'il est utile de pouvoir ajouter des informations telles blocs, divisions, listes... Un schéma destiné à l'encodage des textes permet aussi d'ajouter un balisage fin à des fins de recherche sur un corpus. Certains permettent ainsi de tisser des graphes sémantiques destinés à l'analyse linguistique.
Un schéma qui se destine à la production documentaire se distingue d'une DTD d'encodage en ce qu'il ne répugne pas à structurer des informations qui ne se "voient pas". On le reconnaîtra par un appareillage important de métadonnées, à destination de traitements automatisés. Par exemple, une table des matières n'est pas rédigée par l'auteur, elle est générée sur la hiérarchie des sections, de même pour d'autres navigations, comme Index, Tables des figures, pagination... Il s'y adjoint souvent de nombreux outils libres, reflétant l'exigence et la motivation de ses utilisateurs.
Latex est un format de texte structuré. Le projet a commencé en 1985. La syntaxe n'est pas XML (ni SGML). Le balisage peut être approché de RTF (avec barre oblique inverse "\", accollades "{}" et autres caractères spéciaux "#$%^&_~"), à la différence qu'on n'y spécifie plus la sémantique que la présentation. Ce format est ici mentionné parce qu'il est encore une référence de la documentation scientifique et technique (surtout à une époque où il était difficile de trouver une structuration convenable pour des équations mathématiques).
Il existe ensuite de nombreux outils pour sortir des versions imprimables (postscript, pdf), ou électroniques (HTML, Docbook). Cet exemple est donné car il illustre assez bien ce que demande des rédacteurs exigents sur la structuration de leurs contenus.
Résumé
http://www.docbook.org Docbook est un schéma très complet pour produire du texte structuré (~450 éléments). Sa communauté la plus active est issue de la documentation informatique (en particulier le logiciel libre). Cependant, son état actuel et les outils disponibles le rendent propre à bien d'autres projets rédactionnels (techniques, juridiques, scientifiques ...).
DocBook provides a system for writing structured documents using SGML or XML. It is particularly well-suited to books and papers about computer hardware and software, though it is by no means limited to them. DocBook is an SGML document type definition (DTD). An XML version is available now, and an official XML release is in the works. Because it is a large and robust DTD, and because its main structures correspond to the general notion of what constitutes a book, DocBook has been adopted by a large and growing community of authors. DocBook is supported “out of the box” by a number of commercial tools, and support for it is rapidly growing in a number of free software environments. In short, DocBook is an easy-to-understand and widely used DTD. Dozens of organizations use DocBook for millions of pages of documentation, in various print and online formats, worldwide.
Depuis 1991, DocBook est un schéma/DTD pour écrire des "livres" en XML/SGML. Le projet a débuté dans le monde UNIX, avec l'éditeur O'Reilly, pour coordonner l'effort libre de documentation informatique. Vers 1994, la maintenance et la croissance du schéma ont été confiées à une fondation engageant de nouveaux partenaires, dont Novell et Sun. En 2003, à sa version 4.2, DocBook a conquis des utilisateurs bien au-delà de ses racines ; et de plus en plus de logiciels libres ou commerciaux le supportent. Il s'impose comme le standard rédactionnel.
Les noms. Plusieurs raisons expliquent ce succès, dont une première : les noms. Docbook applique strictement l'intention qu'un document XML sache s'expliquer lui-même, que contenu et structure restent humainement lisibles. Malgré le nombre d'éléments, la quantité d'utilisateurs et d'intérêts, le schéma garde sa cohérence et son évidence. Ainsi, un livre se dira <book/>, une bibliographie <bibliography/>, ou une note de bas de page <footnote/>. On trouve un équipement très complet de métadonnées, d'éléments de navigation (tables des matières, des figures, index, glossaires ...). L'auteur le plus exigent peut y trouver les formes pour exprimer sa pensée, et peut-être, une occasion de la structurer.
Les outils. Le premier outil, et le plus indispensable, est la documentation fournie avec le schéma. Elle est proposée en plusieurs formats, dont certains fort commodes. On regrettera le manque de traductions. Parallèlement, le comité éditorial maintient un jeu très important de transformations (DSSSL, XSLT), assurant que toute structuration (XML) trouve une présentation électronique (HTML) ou imprimée (FO/PDF). Ce double point de vue complémentaire assure les utilisateurs d'un développement réaliste et harmonieux du schéma. Enfin, selon l'esprit logiciel libre, la compétence s'échange en temps réel par 2 listes de diffusion, fédérant une communauté.
Un projet rédactionnel engageant des unités documentaire de l'ordre du livre saura probablement se satisfaire Docbook, qui peut être modifié ou enrichi. La TEI peut aussi rendre ce service, mais elle se destine surtout à l'encodage. Pour une taille de type article, les DTDs généralistes peuvent sembler trop larges, en ce cas elles sont conçues pour pouvoir être restreintes et redéfinies. S'il s'agit de documents multi-schémas, les modules XHTML (tables, listes, blocs ...) peuvent être intéressants à intégrer. L'essentiel est de choisir une structuration suffisante pour rester dans le standard choisi, et pouvoir utiliser des ressources libres et internationales.