---
title: "Les conditions de la sémantique : format texte et balisage"
chapitre: 4
section: 2
bibfile: "data/04.json"
_build:
  list: always
  publishResources: true
  render: never
---

Le format est une notion qui invoque nombre d'enjeux épistémologiques dans le domaine de l'édition, dont certains ont été abordés avec la description de ce terme dans la section précédente{{< renvoi chapitre="4" section="1" >}} — en lien avec les questions de logiciel et de standard —, il est désormais temps d'analyser la condition de l'implémentation d'une dimension sémantique dans le texte.

Faire de la sémantique dans un texte, en vue de produire des artefacts éditoriaux divers, est possible à condition de déterminer un format spécifique qui répond à plusieurs contraintes.
Ces dernières sont d'ordres théoriques et pratiques, et notamment sur les questions de prise en compte des besoins et du contexte, de l'inscription de la démarche dans une approche précise, et des résultats attendus.
La direction prise vers des _formats texte_ de balisage, décrits dans cette section, répond à la nécessité de comprendre et de maîtriser les processus d'édition, et de rendre la chaîne d'édition interopérable voire modulaire.
Un autre impératif est à prendre en compte : la conservation des sources des documents pour un traitement ultérieur et notamment avec des outils et des processus différents que ceux initiaux.
Ici nous n'abordons pas d'autres formats en usage dans le champ de l'édition, dont ceux utilisés par des logiciels de traitement de texte ou de publication assistée par ordinateur, propriétaires ou libres, tout simplement parce qu'ils ne permettent pas d'envisager la constitution d'une chaîne d'édition _numérique_ — comme nous l'avons présenté dans le chapitre précédent{{< renvoi chapitre="3" section="2" >}}.
Nous considérons que le format texte et les langages de balisage permettent d'utiliser le numérique en envisageant de nouvelles modalités éditoriales, plutôt qu'en dupliquant le schème de l'imprimé.
La constitution d'une sémantique compréhensible, lisible et néanmoins puissante permet la maîtrise de la composition du sens, inhérente à toute activité d'édition.
Choisir, délimiter ou créer un format sémantique est aussi une étape dans la construction de chaînes d'édition.
Il s'agit ainsi d'adapter ou de développer des protocoles plutôt que d'adopter des dictats.

Notre argumentaire sur les conditions de la sémantique, qui s'inscrit pleinement dans l'étude des formats dans l'édition, se divise en quatre temps.
Tout d'abord la description du type de format qui permet d'accueillir des balisages divers, le _format texte_.
Il s'agit ensuite de comprendre comment intégrer, dans le format texte, des possibilités de sémantisation des textes, en définissant précisément le terme _balisage_.
Nous établissons une typologie du ou des balisages, afin de relever les enjeux épistémologiques profonds de tels formats.
Enfin, si nous avons déjà donné quelques éléments concernant les _formats de balisage_ en abordant l'histoire des formats sémantiques, nous décrivons plusieurs moments clés du développement de langages de balisage majeurs comme SGML, TEI, HTML ou XML.


### 4.2.1. Définition du format texte

Le format texte est un format de fichier informatique qui ne comporte que des caractères textuels.
Le format texte est lisible par des logiciels qui affichent uniquement ces caractères ou qui les interprètent pour exécuter des actions.

{{< code type="code" legende="Extrait du livre numérique _Anarchism and Other Essays_ d'Emma Goldman, au format TXT, extrait de la plateforme Gutenberg.org" >}}
MINORITIES VERSUS MAJORITIES

If I were to give a summary of the tendency of our times, I would
say, Quantity.  The multitude, the mass spirit, dominates everywhere,
destroying quality.  Our entire life--production, politics, and
education--rests on quantity, on numbers.  The worker who once took
pride in the thoroughness and quality of his work, has been replaced
by brainless, incompetent automatons, who turn out enormous
quantities of things, valueless to themselves, and generally
injurious to the rest of mankind.  Thus quantity, instead of adding
to life's comforts and peace, has merely increased man's burden.
{{< /code >}}

Comme nous pouvons le voir dans cet extrait, le format texte ne contient rien d'autres que des caractères typographiques, seules les majuscules permettent d'identifier un fragment différent du document, en l'occurrence un titre.
Le format texte peut révéler ses éléments de structuration, voire sa sémantique, autant pour les humains que pour les machines, par le biais d'un langage, ce langage pouvant être interprété par un logiciel.
Le format texte est un format qui comporte des instructions univoques.

{{< citation ref="tenen_plain_2017" page="3" lang="en" >}}
Plain text identifies a file format and a frame of mind.
{{< /citation >}}

L'introduction de _Plain Text_ de Dennis Tenen apporte une double dimension technique et épistémologique, indiquant que le choix de ce type de format n'est pas qu'un besoin technologique, il s'agit aussi d'adopter un certain rapport au numérique et au texte.
Comme nous le voyons par la suite, utiliser le format texte peut requérir quelques compétences qui sont liées au format lui-même — et en particulier au langage sémantique — et non au logiciel habituellement associé.
Cette littératie est également une perspective enthousiasmante, puisqu'elle donne plus de maîtrise et de liberté aux personnes qui l'acquièrent.
D'un point de vue plus pratique, voici une définition du _format texte_ extraite du manuel de présentation et de documentation d'Unicode :

{{< citation ref="the_unicode_consortium_unicode_2000" page="2-5 - 2-6" lang="en" >}}
_Plain text_ is a pure sequence of character codes; plain Unicode-encoded text is a sequence of Unicode character codes. In contrast, _fancy text_, also known as _rich text_, is any text representation consisting of plain text plus added information such as language identifier, font size, color, hypertext links, and so on. For example, the text of this book, a multifont text as formatted by a desktop publishing system, is fancy text.
{{< /citation >}}

Pourquoi s'arrêter sur cette définition qui distingue un format _simple_ ou _brut_ et un format _riche_ ?
Tout d'abord parce que The Unicode Consortium est un groupement chargé de définir comment chaque _signe_ est encodé pour que chaque système numérique puisse l'afficher.
Cette initiative est destinée à rendre tout texte compatible, quelle que soit sa langue, afin d'afficher sur n'importe quel dispositif informatique des _symboles_ ou des _glyphes_ tels que les caractères de l'alphabet latin (en prenant en compte la casse ou les diacritiques), les marques de ponctuation en usage dans certaines langues, les kanji japonais, ou encore l'alphabet arabe — pour ne prendre que quelques exemples.
The Unicode Consortium est donc bien placé pour définir ce qu'est le format texte.
Ensuite, cette définition apporte une distinction importante entre deux formats : le premier, le _plain text_, est une suite de caractères sans mise en forme, il s'agit du contenu ; le second, le _fancy text_ ou _rich text_, est l'addition du _plain text_ et d'informations complémentaires indiquant notamment le format, la mise en forme, des liens hypertextes, etc.
Nous retenons cette distinction seulement pour marquer la différence entre un format qui contient les contenus (ou le texte et sa structuration sémantique) et un format qui contient également des éléments de mise en forme (ou le rendu graphique selon le type d'artefact qui est produit).
Nous rejoignons cette définition qui indique en creux que le format texte ne contiendrait que le texte, au sens du texte définit dans "What is Text, Really?" {{< cite "derose_what_1990" >}}, donc des contenus et leur qualification sémantique mais sans l'attribution d'une équivalence graphique.
Nous critiquons toutefois l'emploi du terme "pur", notre position rejoignant celle d'Arthur Perret {{< cite "perret_lheritage_2022" "154" >}}, ce terme apportant de la confusion sur la possible simplicité d'un tel format, et cela implique un jugement par rapport au type de données, notamment la différence avec certains formats qui doivent être interprétés voire exécutés pour être lus ou édités.

Le format texte est lisible _et_ exécutable, c'est ici l'un des points d'achoppement que nous souhaitons souligner.
Ce format peut être à la fois affiché _tel quel_, ou exécuté par une machine qui déclenche des actions en fonction des caractères qui y sont inscrits.
Cette double compréhension, par les humains et les machines, ouvre plusieurs perspectives, comme l'interopérabilité et le choix des modes d'édition.
En étant par défaut _ouvert_, et révélant autant ses contenus que ses instructions, le format texte peut offrir plus facilement des possibilités d'interopérabilité.
En effet, tout fichier au format texte peut être modifié avec n'importe quel éditeur de texte, le format étant décorrélé du logiciel.
Cela signifie aussi que le fichier peut potentiellement rester lisible dans un temps très long.
Ce format ne doit pas nécessairement être édité avec un _éditeur de texte_, d'autres logiciels permettent d'afficher ses contenus voir d'interpréter sa syntaxe (s'il y en a une) afin de faciliter sa compréhension.
C'est le cas du format XML-TEI par exemple, qui peut être lu avec éditeur de texte simple qui n'affiche que les caractères, ou un éditeur de texte plus avancé qui interprète le balisage et affiche une coloration syntaxique pour distinguer les différentes balises, ou encore un logiciel qui accompagne l'écriture (comme l'enchaînement autorisé des balises).
Ces différents modes d'édition interviennent à différents moments d'un travail d'édition ou dépendent du profil des personnes qui réalisent ce travail.
Arthur Perret signale d'autres apports conséquents de ce format comme la stabilité, la fiabilité, le stoïcisme ou la textualité :

{{< citation ref="perret_format_2022" >}}
Et alors, considérez la question suivante : pour tous ces gestes qui passent par le texte, est-ce qu’il vous serait utile de connaître une technique universelle simple, légère, performante, portable, gratuite, pérenne, pouvant rendre toutes sortes de services ? Une sorte de _lingua franca_, de plus petit dénominateur commun de la textualité version numérique ? Songez à la versatilité du couple papier-crayon pour toutes les tâches d’écriture ; transposez-la à l’informatique : vous obtenez le format texte.
{{< /citation >}}

Ces bénéfices conduisent à un autre argument de poids qui explique son adhésion dans le domaine informatique : les états d'un fichier au format texte peuvent être gérés avec des systèmes de gestion de versions tels que Git.
Ce versionnement, difficile avec des encodages _riches_, est possible avec ce type de format.
En effet, les différences entre deux états d'un fichier au format texte peuvent être visualisées très facilement : un caractère a par exemple été supprimé à telle ligne du fichier, et trois autres ont été ajoutées à une autre ligne.
Le format texte est ainsi un format qui représente des avantages certains dans un contexte numérique, tout en nécessitant des phases de conversion ou de transformation pour aboutir à un artefact — c'est ce que nous détaillons par la suite{{< renvoi chapitre="4" section="4" >}}.
Avant d'expliciter comment il est possible d'appliquer une sémantique _avec_ ou _dans_ le format texte, nous explorons ses origines.


### 4.2.2. Origines et distinctions du format texte

D'où vient le format texte ?
Il s'agit d'un des formats les plus utilisés, puisqu'il est très largement employé dans l'informatique comme la source privilégiée des programmes ou des logiciels.
Chaque programme étant ainsi composé d'un certain nombre de fichiers au format texte, et plus spécifiquement dans des langages de programmation eux-mêmes représentés par une série de caractères.
Le format texte est donc partout{{< n >}}De nombreux langages de programmation ne sont toutefois pas basés sur le format texte, Smalltalk est un exemple parmi beaucoup d'autres.{{< /n >}}, et ce depuis les débuts de l'informatique.
Comme nous l'avons dit précédemment, son usage s'explique en raison de sa grande simplicité et de son interopérabilité inhérente.
C'est donc un moyen efficace, durable et compatible de stocker des informations, sans parler du fait que les fichiers dans ce format sont — potentiellement — très légers.
Pour comprendre tout cela, il est possible d'aller ouvrir les fichiers source d'un programme ou d'un logiciel avec un éditeur de texte, la plupart du temps ils consistent en une série de lettres, de chiffres et de symboles typographiques compréhensibles — principalement dans des langues occidentales.
Dans la grande majorité des cas ces fichiers sont donc au format texte, et lisibles directement dans un éditeur de texte.

Plusieurs contextes nécessitent de recourir à des formats exécutables qui ne sont lisibles que dans des environnements très spécifiques.
Le stockage de données relationnelles, par exemple, est facilement réalisé dans des formats qui ne sont pas qu'une suite de caractères.
C'est le cas du format de base de données SQL{{< n >}}Pour _Structured Query Language_ ou Langage de requête structurée en français.{{< /n >}} où l'information est organisée dans des tableaux, à deux dimensions, liés entre eux.
Nous pouvons observer un constat similaire dans le développement de certains programmes qui sont enregistrés dans un format image, notamment pour des raisons de performance.
Ces cas révèlent des besoins en termes d'environnement de travail, il s'agit d'accéder à des données complexes directement depuis _un_ fichier plutôt que par le biais de multiples fichiers au format texte avec des syntaxes diverses.
Un fichier exécutable par un système d'exploitation est, selon les objectifs visés, parfois plus pertinent qu'un format texte.
Un exemple parmi d'autres est la façon dont l'éditeur de texte Vim gère les données : le fichier texte est enregistré à chaque fois que la commande _enregistrer_ est appelée, mais dès qu'une lettre est _tapée_ Vim stocke temporairement ces données dans le _buffer_, qui n'est pas un fichier au format texte.
C'est le format SWP (pour _swap_ ou échange en français) qui est utilisé pour cet usage.
Son encodage n'est pas au format texte, son ouverture avec un éditeur de texte révèle ainsi une suite de caractères incompréhensibles, que seul logiciel Vim peut interpréter.
Si des formats de base de données ont toutefois adoptés le format texte, et si Vim enregistre les données finales dans un fichier au format texte, il est intéressant de noter pourquoi ce n'est pas le type de format qui pourrait remplacer tous les autres.
Il y a toutefois une tendance, depuis quelques années, à se tourner vers des formats texte pour l'écriture ou l'édition, et pour expliquer ce phénomène nous pouvons reprendre l'exemple des traitements de texte en général et du format DOC et de Microsoft Word en particulier.

Word, et son format DOC, a dominé les usages dans le champ des traitements de texte pendant plusieurs années.
Nous l'avons déjà signalé{{< renvoi chapitre="4" section="1" >}}, le format DOC est dit _binaire_ ou _exécutable_, il ne comporte donc pas qu'une série de caractères typographiques — en l'occurrence il s'agit de scripts, d'informations de mise en forme, etc.
Impossible de lire un fichier `.doc` avec autre chose que Word{{< n >}}D'autres logiciels étaient et sont capables de lire ce format, parfois avec des pertes d'information.{{< /n >}}, comme un éditeur de texte.
Le choix d'adopter un standard ouvert et normalisé, Office Open XML, permet une certaine compatibilité.
Le format DOCX est une implémentation de ce standard, qui encapsule un certain nombre de fichiers texte — à la façon du format EPUB —, permettant en théorie à plusieurs programmes d'y accéder.
L'ouverture logicielle ne suffit pas, tant il est compliqué de comprendre l'encodage verbeux du schéma XML utilisé.
Pour des opérations simples tel qu'un texte structuré de façon très sommaire, ce format implique une forte opacité comme nous pouvons le voir ci-dessous.

{{< code type="code" legende="Contenu du fichier document.xml d'un document enregistré au format DOCX (de nombreux autres fichiers composent le fichier DOCX), le mot bonjour est perdu dans un ensemble de balises XML" >}}

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:document xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:w10="urn:schemas-microsoft-com:office:word" xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing" xmlns:wps="http://schemas.microsoft.com/office/word/2010/wordprocessingShape" xmlns:wpg="http://schemas.microsoft.com/office/word/2010/wordprocessingGroup" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:wp14="http://schemas.microsoft.com/office/word/2010/wordprocessingDrawing" xmlns:w14="http://schemas.microsoft.com/office/word/2010/wordml" xmlns:w15="http://schemas.microsoft.com/office/word/2012/wordml" mc:Ignorable="w14 wp14 w15">
<w:body><w:p><w:pPr><w:pStyle w:val="Normal"/><w:bidi w:val="0"/><w:jc w:val="left"/><w:rPr></w:rPr></w:pPr><w:r><w:rPr></w:rPr>
<w:t>Bonjour</w:t>
</w:r></w:p><w:sectPr><w:type w:val="nextPage"/><w:pgSz w:w="12240" w:h="15840"/><w:pgMar w:left="1134" w:right="1134" w:gutter="0" w:header="0" w:top="1134" w:footer="0" w:bottom="1134"/><w:pgNumType w:fmt="decimal"/><w:formProt w:val="false"/><w:textDirection w:val="lrTb"/></w:sectPr></w:body></w:document>

{{</ code >}}

Dans les quelques lignes de XML ci-dessus nous découvrons le mot "Bonjour", perdu dans un ensemble de données qui définissent autant le format que la façon dont ces sept lettres doivent être disposées sur la page — les informations concernant le rendu graphique sont stockées dans un autre fichier.
L'hégémonie des formats DOC ou DOCX est pourtant remise en cause avec l'apparition de logiciels plus simples, dédiés à l'écriture et moins aux tâches bureaucratiques, comme le signale Matthew Kirschenbaum dans _Track Changes_, son enquête sur les traitements de texte {{< cite "kirschenbaum_track_2016" "235-247" >}}.
L'usage d'applications en ligne telles que Google Docs vient notamment remettre en cause ce monopole.
Aussi, des solutions alternatives apparaissent au début des années 2010, loin des logiciels monopolistiques ou des applications de géants du numérique, avec cette volonté, dans certains domaines, de prendre soin du texte et des personnes qui interviennent dessus {{< cite "maxwell_care-ful_2022" >}}.
C'est le cas du logiciel iA Writer au début des années 2010, uniquement dédié à l'écriture plutôt qu'à la création de documents bureautiques.
iA Writer utilise justement un format texte — en l'occurrence Markdown, que nous présentons longuement dans l'étude de cas qui suit{{< renvoi chapitre="4" section="3" >}} —, format qui peut être utilisé avec de nombreux autres logiciels.
Il s'agit d'une forme de retour au format texte, avec l'apparition d'un nouveau type d'application qui permet de l'éditer, sans pour autant enfermer des utilisateurs dans des formats propriétaires ou limités à certains logiciels.
Dans le cas de Markdown et du logiciel iA Writer, le format et le texte lui-même ne font plus qu'un, pour reprendre les mots d'Oliver Reichenstein (l'un des créateurs de iA) :

{{< citation ref="reichenstein_multichannel_2016" lang="en" >}}
In Plain Text the text is the source. With Rich Text we see a simulation. What we see may please us, but below the surface our word processor secretly builds a more complex text in code.
{{< /citation >}}

iA Writer est un exemple intéressant, parce qu'il est entièrement conçu autour d'un format texte, pour en développer des fonctionnalités indépendantes.
Dit autrement, ici le logiciel n'influence pas les spécifications du format, mais il est construit autour de lui.
Le concept de _developer experience_, entendu comme un ensemble de processus et d'outils simples et efficients basés sur des standards plutôt que sur des interfaces et des fonctionnalités complexes {{< cite "fagerholm_developer_2012" >}}, a surement influencé le développement de iA Writer.
Notons que de nombreux logiciels d'écriture basés sur le format texte Markdown existent aux côtés d'iA Writer, et qu'il s'agit là d'usages difficiles à quantifier, mais toujours minoritaires par rapport aux traitements de texte classiques — et plus précisément Microsoft Word.

Le format texte, dans le cas de l'édition — prise au sens très large —, implique une transformation pour obtenir divers artefacts, des formats dits _de sortie_.
Les traitements de texte sont des machines à tout faire, et intègrent des fonctions d'export — notamment en PDF — quand leur format ne devient pas une finalité en soi.
Le format texte implique ainsi de découpler les étapes d'édition, le format texte concernant d'abord l'écriture — l'inscription et la fixation de données.

Nous avons donné quelques clés de compréhension concernant les origines du format texte et son usage dans les domaines de l'informatique ou de l'édition.
Ce que nous n'avons pas encore dit, c'est la manière dont les informations contenues dans un format texte peuvent être inscrites, ou comment faire de la sémantique dans un environnement où tout est (d)écrit avec des caractères.


### 4.2.3. Du format texte à la sémantique

Le format texte amène à considérer une épistémologie de la connaissance tournée vers l'autonomie et l'ouverture.
Encore faut-il disposer d'un moyen pour y exprimer des niveaux de sémantique, sans quoi l'intérêt de ce type de format est très limité.
Une des étymologies grecques du terme "sémantique" est notamment σῆμα, soit "signe, marque".
Dans notre cas la question de _sémantiser_ un texte revient à y apposer des marques, afin d'identifier différents niveaux d'information ou de valeurs textuelles.
Ces marques doivent être compréhensibles par des personnes humaines, mais aussi par des programmes informatiques qui les interprètent.
Le premier enjeu ici est donc de déterminer une _syntaxe_ pour réaliser ce double objectif, la difficulté résidant dans les contraintes du format texte — une suite de caractères — et dans les éventuelles ambiguïtés ainsi générées — il s'agit en effet de définir des éléments textuels qui ne sont pas des mots, qui sont des paratextes.
Les symboles typographiques utilisés pour _marquer_ le texte, que ce soit des lettres, des marques de ponctuation ou tous autres signes disponibles dans la grande variété des glyphes, doivent être lisibles par des humains ou des machines.
L'objectif est donc d'abord de _signifier_ des valeurs plutôt que d'attribuer un rendu graphique pour les différents éléments d'un texte ; car tout texte est _marqué_, révélant des choix typographiques ou un agencement graphique particulier du texte sur la page ou sur l'écran.

{{< citation ref="mcgann_marking_2004" page="198-199" lang="en" >}}
All text is marked text, as you may see by reflecting on the very text you are now reading. As you follow this conceptual exposition, watch the physical embodiments that shape the ideas and the process of thought. Do you see the typeface, do you recognize it? Does it mean anything to you, and if not, why not?
{{< /citation >}}

Comme le dit Jerome McGann ci-dessus, les _incarnations physiques_ qui nous permettent de comprendre le sens sont en soi implicites, mais toujours présentes et sous différentes formes.
Toutefois des considérations uniquement visuelles ne prennent pas en compte une attribution _déclarative_ du sens qui dépasse un environnement graphique, environnement dans lequel l'interprétation ne peut être calculée de façon univoque.
C'est une pratique courante des traitements de texte avec le mode WYSIWYG.
Ce mode _What You See Is What You Get_ — ce que vous voyez est ce que vous obtenez, en français — consiste à appliquer une mise en forme pour distinguer par exemple un titre (dans une police de plus grande taille) du texte principal (dans une police de plus petite taille), ou d'autres éléments comme un texte en emphase (par exemple en italique) ou une liste non ordonnée (par exemple avec un retrait et un tiret devant chaque entrée de cette liste) ; mais cette mise en forme n'a pas toujours une valeur sémantique.
L'héritage de l'imprimé, avec ce rendu visuel omniprésent et la logique de la page, est remis en cause dans un environnement où tout peut être calculé.
Nous l'avons vu précédemment{{< renvoi chapitre="4" section="1" >}}, des moyens ont été mis en œuvre dès les années 1960 pour déclarer une sémantique calculable et sans ambiguïté, via le format texte ; que ce soit avec GML en 1969, puis TeX en 1978 et SGML en 1986 {{< cite "blanc_technologies_2018" >}}.
C'est la fonction du _balisage_ que de donner du sens au texte dans le format texte, pour pouvoir être traité dans un environnement numérique.
Le balisage est ainsi le compagnon du format texte.

Qu'est-ce que le balisage ?
Une balise est un point de repère, un élément qui peut être facilement identifié pour fixer une limite.
En dehors du champ du livre il s'agit de placer une signalisation en bois sur la route, sur la mer ou autour de rails, afin de circuler.
Pour le texte l'enjeu est très similaire, c'est notre regard qui doit être guidé pour comprendre quelle valeur est attribuée à des portions de lettres, de mots ou de phrases, comme nous pouvons le voir avec l'exemple ci-dessous balisé dans le format AsciiDoc :

{{< code type="code" legende="Phrase balisée dans le format AsciiDoc avec deux mots en emphase, le premier en italique et le second en gras" >}}
Les _balises_ sont des éléments typographiques, textuellement graphiques, qui permettent d'identifier le *sens*.
{{< /code >}}

L'usage de ce terme pour des noms d'initiatives scientifiques va dans ce sens : la revue française _Balisages_ se situe "ainsi à l'intersection des sciences de l’information et de la communication, de l'histoire du livre et des bibliothèques, et de l'anthropologie des savoirs" ; ou la conférence annuelle du même nom (au singulier), "Balisage", qui se définit comme "where serious markup practitioners and theoreticians meet every summer".
L'équivalent de "balisage" en langue anglaise est _markup_, contraction de _mark_ et _up_, et est issu non pas d'objets en bois, mais d'une pratique d'annotation des manuscrits pour faciliter le travail des imprimeurs.
_Baliser_ ou _marquer_ est alors une pratique qui consiste à ajouter des indications pour que la composition typographique soit au plus proche des intentions de l'éditeur, il s'agit d'une formalisation destinée à donner une autre dimension au texte.
À ce titre ce travail d'annotation est probablement plus constitutif de l'acte d'édition que les _intentions_ parfois ambigües d'un éditeur.
Cette origine étymologique nous permet de noter le saut effectué entre un modèle imprimé, où les informations ont d'abord une valeur pour la composition graphique, vers un modèle numérique, où l'importance devient le sens qui se traduit ensuite en une forme par un calcul ou une _computation_.
Nous passons d'instructions pour un rendu graphique à l'adoption de règles de traitement pour attribuer du sens.
Du WYSIWYG nous allons vers le WYSIWYM — pour _What You See Is What You Mean_ ce que vous voyez est ce que vous signifiez, en français.

{{< citation ref="mcgann_new_2014" page="169" lang="en" >}}
All texts are marked texts, i.e., algorithms—coded sets of reading instructions.
{{< /citation >}}

Pour reprendre Jerome McGann, tout texte comporte des instructions de lecture, encore faut-il que ces instructions soient univoques, et autant pour des personnes qui vont _voir_ ou _déchiffrer_ ces informations, ou pour des machines qui vont les interpréter caractère par caractère.
Ainsi si nous établissons une distinction stricte entre des informations de composition et l'application d'une sémantique, tout texte demeure un texte balisé.
La principale différence réside dans les valeurs qui sont données à des fragments de texte et à la manière de les attribuer _dans_ le format texte, de façon lisible et sans ambiguïté.
Le format texte est le candidat idéal pour exprimer une sémantique de manière intelligible, manifeste et transparente.

{{< definition type="definition" intitule="Format de balisage" id="formatdebalisage" >}}
Un format de balisage est une série d'instructions pour modéliser une information et plus particulièrement un texte.
Ces instructions doivent être univoques, afin d'être compréhensibles par des personnes qui les lisent ou les machines qui les traitent.
Tout fragment de texte peut ainsi être balisé pour déclarer le sens qu'il porte, marquant une distinction entre des données textuelles telles qu'une citation, un paragraphe ou même une date.
Les _balises_ sont des points de repères, permettant de naviguer dans un texte et de construire des modélisations épistémologiques.
{{< /definition >}}

En même temps qu'explorer certaines des façons de faire qui sont adoptées pour appliquer une sémantique dans cet environnement contraint, il est nécessaire d'établir une typologie des balisages, puis d'analyser quelques-unes de leurs limites.


### 4.2.4. Histoire et typologie

Comme nous l'avons exprimé en creux précédemment, il y a plusieurs façons de baliser un texte qui ne sont pas tant des implémentations techniques que le reflet d'un positionnement par rapport au texte pour des applications déterminées — encodage, composition, production simultanée de plusieurs artefacts, archivage, etc.
Il peut s'agir par exemple de _composer_ un texte pour obtenir un rendu graphique, ou conserver toutes les informations liées à la structuration sémantique du document pour un archivage.
Adopter un type de balisage résulte d'une approche heuristique, qui consiste à définir une manière de signifier.
Pour comprendre les enjeux liés au balisage nous devons d'abord comprendre son émergence dans des buts différents, révélant ainsi une typologie riche, puis explorer les types de choix techniques existants. 

Tout d'abord, que faut-il baliser ?
Il faut prendre en compte plusieurs niveaux dans un texte, quel que soit le balisage.
Nous établissons ici un rapide panorama qui ne se veut pas exhaustif, et principalement axé autour de documents de type _livre_, dans le champ des lettres.
Une distinction entre deux niveaux du texte est nécessaire ici.
Chaque mot ou suite de mots peut être identifié, c'est le cas de l'attribution de l'emphase à un ou plusieurs termes pour marquer leur importance, et qui peut se traduire par une mise en forme en italique.
Cette suite de caractères, souvent définie comme un _élément en ligne_ — _inline-level content_ en anglais —, ou _élément de texte_, dans les descriptions de balisages comme SGML ou HTML, peut s'étendre d'un caractère à plusieurs phrases.
Cette délimitation ne dépasse pas la _ligne_ comme son nom l'indique, la limite étant le paragraphe.
Ce dernier est le second niveau, défini comme un _élément de bloc_ ou _bloc de texte_ — _block-level content_ en anglais.
Cette unité peut concerner des données comme une suite de mots qui forment un ensemble distinct sémantiquement et graphiquement d'une autre série de mots, une _zone_ qui dépasse la ligne, comme un paragraphe, une figure et sa légende, ou encore un titre — la diversité des _éléments de bloc_ est grande.
Enfin, il s'agit de décrire le document lui-même, et c'est là une distinction plus délicate avec la notion de métadonnées.
Voilà une des limites du balisage, puisque dans certains cas cette description _méta_ d'un document est déléguée à un autre type de format, le format de _sérialisation_ de données — nous décrivons plus longuement cette distinction dans l'étude de cas qui suit{{< renvoi chapitre="4" section="3" >}}.

L'histoire du balisage est longue à l'échelle de l'informatique, et est principalement liée à des besoins industriels de production et de gestion de documents, ou à des contraintes de diffusion scientifique.
Ainsi les cas d'expérimentation, notamment dans des domaines non marchands, artistiques ou littéraires, sont minoritaires.
La typologie qui suit est basée sur les travaux de James H. Coombs, Allen H. Renear et Steven J. DeRose {{< cite "coombs_markup_1987" >}} qui restent pertinents sur plusieurs aspects même après plus de trente ans.

{{< figure type="figure" src="balisage-typologie.png" legende="Figure extraite de l'article de James H. Coombs, Allen H. Renear et Steven J. DeRose, \"Markup systems and the future of scholarly text processing\" publié en 1987" >}}

Si nous considérons une typologie progressive partant d'une syntaxe avec peu de paramètres et allant vers une plus grande précision sémantique, le format texte est d'abord utilisé _sans balisage_.
C'est le cas avec le premier livre numérique diffusé par Michael Hart et qui donne lieu au projet Gutenberg, comme nous l'avons vu précédemment{{< renvoi chapitre="3" section="2" >}}.
Il s'agit, d'une certaine façon, d'un texte sans distinction apparente — autre que des sauts de ligne et l'usage éventuel des majuscules.
Nous considérons qu'il s'agit ici soit d'une absence totale de balisage, soit d'un balisage dit _présentationnel_ dans le cas de l'usage d'une composition typographique quelle qu'elle soit.
D'une certaine façon, les traitements de texte utilisent une forme de balisage _présentationnel_, en faisant un usage massif d'un rendu graphique y compris pour le texte en cours d'écriture.
Le terme de _markup_ en anglais — que nous traduisons par balisage et vice versa — provient d'une pratique d'annotation pour la préparation de documents à imprimer.
Il s'agit d'un balisage _procédural_ qui consiste à décrire le comportement du texte dans une perspective de rendu graphique, et donc à décomposer l'écriture de l'édition.
Cette pratique, largement répandue pendant toute une période, ne porte pas d'informations sémantiques, à moins de faire une correspondance par exemple entre un retrait d'un bloc de texte et le fait qu'il s'agisse d'une citation longue.
La seule manière d'exprimer une information sémantique sur un support imprimé est l'utilisation d'un langage graphique : une taille de police plus grande pour un titre, et beaucoup plus petite pour une note.
Par ailleurs, le balisage _procédural_ considère le texte comme un flux, et non comme un ensemble de données, ce qui engendre des instructions qui ne valent que dans une lecture linéaire du document.
GML (Generalized Markup Language) est le point d'articulation entre un balisage _procédural_ et un balisage _descriptif_, et plus spécifiquement une tentative de formaliser des instructions autant pour les humains que pour les machines.
GML — ou plus exactement IBM GML puisqu'il s'agit d'une initiative de l'entreprise informatique IBM{{< n >}}Notons que IBM est également impliquée dans ce qui peut souvent être considérée comme la naissance des humanités numériques avec le projet _Index Thomesticus_ de Roberto Busa.{{< /n >}} — est créé en 1969 pour remplacer le système de composition PostScript.
Le but de GML est la composition de documents en vue de les imprimer, en séparant le contenu de son format.

{{< citation ref="ibm_document_1985" page="iii" lang="en" >}}
The Generalized Markup Language (GML) is a language for document description. It can be used to describe the structure and text elements (parts) of a document without regard to the processing that may be required to format them.
{{< /citation >}}

Le principe de distinction entre les informations qui concernent le contenu d'un document, sa dimension sémantique et son équivalence graphique, est à l'origine de GML et des langages de balisage qui suivront.
Dit autrement, il s'agit de séparer le contenu de sa présentation, ou encore de rendre le contenu indépendant de son format, comme le décrit Charles F. Goldfarb, l'un des créateurs de GML puis de SGML :

{{< citation ref="goldfarb_roots_1999" lang="en" >}}
Many credit the start of the generic coding movement to a presentation made by William Tunnicliffe, chairman of the Graphic Communications Association (GCA) Composition Committee, during a meeting at the Canadian Government Printing Office in September 1967: his topic -- the separation of information content of documents from their format.
{{< /citation >}}

Avec GML le rendu graphique est toujours l'objectif final, via son implémentation dans le système DCF (Document Composition Facility) d'IBM.
Les indications se font beaucoup plus précises pour lever toute ambiguïté grâce à l'utilisation de _macros_, héritées de pratiques de programmation — une _macro_ est une suite de caractères indiquant une fonction comprise par un programme ou un logiciel.
Notons qu'au même moment Brian Reid crée le langage de balisage Scribe (accompagné d'un compilateur),qui comporte une séparation stricte entre le contenu et sa présentation {{< cite "reid_scribe_1980" >}}.
À la suite de GML émerge un second balisage en 1986, _descriptif_ cette fois, avec SGML (Standard Generalized Markup Language) {{< cite "goldfarb_sgml_1990" >}}.
SGML considère un document comme un ensemble de données, chacune pouvant être identifiée via l'utilisation de balises englobantes.
Chaque portion — en _bloc_ ou en _ligne_ — qui nécessite des indications sémantiques est _encadrée_ par des balises ouvrantes et fermantes indiquées avec des chevrons, comme `<quote>ceci</quote>`.
Entre la création de GML puis de SGML, d'autres tentatives sont développées pour baliser du texte, comme le format TeX puis le système de composition qui l'accompagne LaTeX{{< renvoi chapitre="3" section="3" >}}.
Donald Knuth crée TeX afin d'obtenir des documents mis en forme avec une forte exigence typographique.
Il s'agit ici d'un balisage à la fois _procédural_ et _descriptif_, des macros permettant autant d'indiquer ponctuellement des actions nécessaires pour la composition de document ou attribuant une valeur en englobant des portions de texte.

En 1987 émerge un autre format de balisage _descriptif_, TEI, destiné à encoder et non à composer des documents.
Nous avons déjà présenté ce format{{< renvoi chapitre="4" section="1" >}}, pensé comme un moyen de définir en premier lieu le sens d'un texte, et plus spécifiquement dans une activité d'encodage de documents initialement imprimés.
Notons que la TEI est créée quelques années avant des formats plus populaires comme XML ou HTML.
La TEI est d'abord une application de SGML, avant de devenir un schéma XML.

Le format HTML est développé à partir de 1990, également comme une application de SGML, Tim Berners-Lee s'inspire de ces principes en créant une série de balises utiles à l'affichage de documents dans un navigateur web, mais dont le rendu graphique n'est pas la seule finalité.
Dès les débuts du Web, l'objectif est d'en permettre un usage très large, y compris à des personnes en situation de handicap.
Le sens donné au texte est donc autant destiné à être interprété puis affiché par un navigateur web, qu'à être transcrit dans diverses formes pour des personnes ne pouvant _voir_ le rendu _graphique_.
La distinction forte entre HTML et XML peut être explicitée avec les formats XHTML et HTML5 : le premier est un schéma XML, dont l'usage ne peut qu'être rigoureux, qui est censé permettre l'utilisation de puissants outils liés à XML dans des environnements web ; le second est une évolution du langage HTML avec la dimension permissive qui le définit.
La déconnexion entre XML et HTML intervient à un moment où la communauté qui travaille avec ces formats est plus tournée vers les outils du Web et moins vers des usages académiques.
Cette déconnexion révèle aussi des limites intrinsèques à tout balisage, et le type de modélisation épistémologique qui vient avec.
Nous analysons quelques-uns des rapports avec le sens qui jalonnent la création de syntaxes.


### 4.2.5. Les limites du balisage

Les différentes initiatives de balisage du texte, qui débutent avec ce principe fort d'une séparation de la structure d'un document et de sa représentation graphique, sont sujettes à des limites qu'il faut mentionner.
Elles ne représentent pas un barrage en soi, mais constituent un certain nombre de contraintes inhérentes à toute implémentation technique de principes théoriques.
Plus encore, ces limites révèlent des questionnements épistémologiques précieux pour notre recherche, que nous étudions sous trois angles.
Il s'agit tout d'abord de la question des types de balisage, chacun hérité de divers domaines comme l'informatique, manifestant un rapport au texte et aux artefacts qui peuvent en être produits.
Le deuxième angle concerne des enjeux sémantiques complexes quand il s'agit de baliser des éléments qui se chevauchent, problème largement abordé notamment par la communauté TEI.
Enfin, la troisième approche concerne le degré d'adoption des balisages et les tentatives de détournement de certains d'entre eux.
L'intérêt ici est d'explorer des limites théoriques et pratiques qui remettent en perspective cette recherche d'une précision sémantique détachée des impératifs du modèle imprimé.
Toute la difficulté réside ici dans la perspective d'une _mise en calcul_ du texte, en appliquant des algorithmes à des marques typographiques.

Il n'y a pas un mais des balisages, de GML jusqu'à XML en passant par TeX ou HTML, et sans mentionner des balisages dits _légers_ qui sont abordés dans l'étude de cas qui suit{{< renvoi chapitre="4" section="3" >}}.
Si jusqu'ici nous n'avons principalement parlé que de _balisage_, il est plus juste d'utiliser le terme de _langage_ pour qualifier l'usage de caractères typographiques pour marquer la sémantique des documents au format texte.
Ces langages de balisage font appel à différents types de mécanismes pour identifier des portions de textes et leur attribuer une valeur — sémantique.
Pour expliciter cela nous montrons la différence entre les _macros_ de TeX et les balises de HTML, pour signifier sémantiquement la même chose, et dans l'objectif de produire un artefact avec rendu graphique, comme dans l'exemple ci-dessous — rendu graphique, balisage au format TeX, et balisage au format HTML :

{{< figure type="figure" src="balisage-exemple-rendu-graphique.png" legende="Rendu graphique d'un extrait de document rédigé et édité par l'auteur" >}}

{{< code type="code" legende="Extrait d'un document balisé avec LaTeX, comprenant plusieurs niveaux d'information" >}}
\title{Les fabriques d'édition : un double mouvement éditorial}
 
\author{Antoine Fauchié}
 
\begin{document}
\maketitle

Les technologies de l'édition, et plus particulièrement de l'édition
numérique, ont beaucoup évolué depuis le début des années 2000, avec
l'apparition de chaînes de publication qui s'éloignent peu à peu des
outils classiques d'édition. Fabriquer une publication, et plus
spécifiquement un livre, est une opportunité pour certaines structures
de construire leurs propres outils d'édition et de publication. Nous
présentons plusieurs initiatives d'édition, basées sur ce que nous
nommons des \emph{fabriques d'édition}, afin d'observer et
d'analyser ces nouvelles façons de faire, d'éditer, comme un nouveau
mouvement éditorial.
{{< /code >}}

{{< code type="code" legende="Extrait d'un document balisé avec HTML avec différents types de balises" >}}
<title>Les fabriques d'édition : un double mouvement éditorial</title>
<meta name="author" content="Antoine Fauchié">
</head>
<body>
<h1>Les fabriques d'édition : un double mouvement éditorial</h1>
<p>Les technologies de l'édition, et plus particulièrement de l'édition
numérique, ont beaucoup évolué depuis le début des années 2000, avec
l'apparition de chaînes de publication qui s'éloignent peu à peu des
outils classiques d'édition. Fabriquer une publication, et plus
spécifiquement un livre, est une opportunité pour certaines structures
de construire leurs propres outils d'édition et de publication. Nous
présentons plusieurs initiatives d'édition, basées sur ce que nous
nommons des <em>fabriques d'édition</em>, afin d'observer et
d'analyser ces nouvelles façons de faire, d'éditer, comme un nouveau
mouvement éditorial.</p>
{{< /code >}}

Un texte balisé avec LaTeX fait appel à des macros ou à des commandes, permettant de déclarer les caractéristiques d'une portion de texte ou d'exécuter une action.
Si une macro comme `\emph{ceci est un texte en emphase}` est très similaire à une balise comme `<em>ceci est un texte en emphase</em>` — le texte concerné est balisé avant et après, et la balise dispose d'un identifiant clair —, en revanche la commande `\maketitle` est un fonctionnement inconnu pour le langage HTML qui ne dispose pas d'un système de publication intégré — puisque c'est le navigateur qui se charge d'interpréter les informations.
En revanche la dimension sémantique de HTML est plus forte que TeX, l'élément `<title>` permettant de spécifier le titre du document et l'élément `<h1>` permettant de déclarer le titre principal de la page — quand bien même cette page ne correspond plus à son équivalent syntaxique imprimé.
Dans les deux cas il manque une modélisation du texte, nécessaire au-delà du balisage pour prévoir justement où va se situer le titre du document et comment l'exprimer — graphiquement ou sémantiquement —, et c'est précisément ce que nous nous proposons d'explorer par la suite{{< renvoi chapitre="4" section="4" >}} avec le concept d'_acte éditorial sémantique_.
Les choix de balisage portent donc des modélisations et des manières de faire.

Autre limite liée au balisage, le problème récurrent et très documenté qui concerne une question liée aux principes de SGML, et ses applications comme HTML ou XML : le chevauchement.
En effet les balises ne peuvent pas se _chevaucher_, en HTML il est par exemple impossible d'écrire `<em>mot <strong>très</em> important</strong>`.
Une solution possible serait `<em>mot <strong>très</strong></em> <strong>important</strong>`, soit une façon plus _verbeuse_ d'exprimer une structure similaire.
Des cas sont bien plus complexes, lorsqu'il s'agit notamment de baliser des citations qui passent d'un paragraphe à un autre, comme le signale de façon détaillée Steven DeRose {{< cite "derose_markup_2004" >}}.
En SGML une solution a été trouvée, CONCUR, pourtant impossible à transposer dans des langages comme XML ou HTML, pour des raisons d'interprétation :

{{< code type="code" legende="Exemple de balisage avec SGML CONCUR, extrait de l'article de Steven DeRose" >}}
<(DTD1)p>And the Lord said,
<(DTD2)q>Read my lips: Do not murder.</(DTD1)p>
<(DTD1)p>Be nice to each other instead.</(DTD2)q>
And the people said "Amen."</(DTD1)p>
{{< /code >}}

Un langage a même été développé pour répondre à ce type de besoin, TAGML (pour Text as Graph Markup Language) {{< cite "bleeker_between_2020" >}}, basé sur un système de balises et de suffixes : `[s|L1>Ceci est un [del|L2>exemple<del] illustratif.<s]`.
Des expérimentations ont aussi été menées pour transposer ce type de _marquage_ dans XML ou XML-TEI.
TeX, en tant que langage de balisage, accompagné de LaTeX et d'un _paquet_ spécifique, combinant également ces différentes approches comme nous pouvons le voir dans cet exemple où le balisage de portions de texte destinées à la création d'un index chevauche celui des paragraphes :

{{< code type="code" legende="Exemple de quelques lignes de LaTeX avec le chevauchement de l'indexation d'un fragement et de deux sections" >}}
\section{Markdown}
\index{markdown|(}
Le format Markdown est un format de balisage léger, dont la syntaxe est réduite à quelques signes typographiques.

\section{La syntaxe de Markdown}
\begin{quote}
Thus, Markdown. Email-style writing for the web.
\end{quote}

\index{markdown|)}
{{< /code >}}

Ces questions de chevauchement semblent anecdotiques, elles révèlent pourtant la complexité d'une formalisation claire et sans ambiguïté, et les multiples tentatives de réduire ces problèmes dans des environnements variés — SGML ou TEI pour le balisage sémantique et TeX/LaTeX qui est plus spécifiquement tourné vers la composition graphique.

Une autre limite aperçue précédemment est le degré de compréhension des langages de balisage, qui conduit à la création d'autres manières de _marquer_ le texte.
HTML, LaTeX ou TEI sont des langages complexes, même sans la question de la gestion délicate du chevauchement.
Ils requièrent une connaissance des éléments, balises ou macros et de leur fonctionnement entre eux.
Ce sont aussi des systèmes de balisage verbeux, les éléments qui les composent pouvant être nombreux — parfois augmentés par des attributs —, ce qui implique beaucoup de _bruit_ autour du texte initial{{< n >}}Si tant est qu'il y ait un texte _initial_.{{< /n >}}.
Cette complexité est parfois réduite grâce à des logiciels spécialisés — typiquement oXygen pour XML ou XML-TEI —, facilitant la saisie des éléments ou proposant une vue sans les balises afin d'accéder à un rendu graphique.
Il est ainsi possible de _dissimuler_ des éléments syntaxiques pour faciliter leur saisie via un mode "auteur".
Ce type de solution pose plusieurs questions, et notamment celle de la maîtrise du langage sémantique.
En disparaissant, les moyens mis en œuvre pour marquer le texte deviennent confus, et c'est la capacité même d'écrire le texte quel qu'il soit qui est remise en cause.
Si nous pouvons nous accorder sur le fait que la connaissance des centaines de balises de la TEI est impossible, il est en revanche envisageable de considérer des étapes de balisage préalables plus simples, plus _légères_.
Et donc d'adopter d'autres langages pour traiter des _sources_, sans pour autant délaisser la richesse des langages issus notamment de SGML.
Ces initiatives, qui relèvent d'une forme de détournement, sont les langages de balisage dits _légers_ que nous analysons dans l'étude de cas qui suit.
Ils présentent un fort intérêt pour l'usage du balisage sémantique dans l'édition, remettant en cause les modèles puissants mais néanmoins contraignants tels que TeX, TEI ou même HTML.
L'idée ici est de disposer d'instructions claires et univoques, mais aussi plus restreintes et utilisables dans des environnements très divers.
L'enjeu est également de réduire les moyens nécessaires à une pratique d'écriture ou d'édition _sémantique_.