Lorsqu'on encode un fichier en XML, bien souvent, on ne prend pas le temps, avant de se lancer à proprement parler dans le codage, de réfléchir à une question simple, mais pourtant essentielle : qu'est-ce-qu'on veut encoder ? Cette question a l'air anodine, mais la réponse peut faire varier de façon très importante la structure du fichier et le choix des balises. Je voudrais essayer de montrer avec ce billet l'impact de cette question dans les stratégies d'encodage.
Avant de continuer et après tous ces semaines à parler de RDF, il est peut-être utile de rappeler que le XML, dans son utilisation première, est un langage à balises permettant de caractériser une portion d'informations à l'intérieur d'un document. A l'inverse de RDF, dont le but est de décrire l'information en elle-même, c'est à dire son sens, XML permet de décrire la structure de l'information dans le contexte d'un document précis. Ainsi, une même portion d'informations peut être encodée de différentes façons dans deux cas différents avec la même grammaire XML, alors qu'elle a le même sens. A travers cette définition et les billets précédents sur RDF, j'espère que la différence apparaît mieux.
L'extensibilité de XML est infinie, il est possible d'encoder chaque mot voire chaque lettre si vous le souhaitez. Évidemment, si vous utilisez une grammaire XML, vos possibilités seront restreintes par celle-ci. Mais, certaines grammaires comme la TEI1 ouvrent ces possibilités.
Lorsque je suis en face d'un nouveau texte à encoder, je me pose toujours la même question : quelles informations sont utiles à encoder ? L'encodage représentant un travail fastidieux, il est inutile de surcharger le choix de balises ce qui complique souvent inutilement le fichier XML. Deux critères me permettent de faire mes choix :
Pour quels informations l'auteur ou l'éditeur veut-il voir une mise en avant dans le résultat final mis en page que ce soit en papier ou avec un navigateur Web ? Pourquoi ces informations-là ? (exemple : un titre d'ouvrages ou un mot étranger sont habituellement mis en avant pour faire apparaître leurs particularités, on va le rendre graphiquement en italique)
Quels informations veulent-ils ensuite utiliser pour dresser des listes, des index ou mettre en place des interrogations ?
La plupart du temps, ces deux critères/questions me permettent de résoudre 95% des choix de balises pour les portions informations à encoder à l'intérieur d'un paragraphe, ce qu'on appellerait les micro-structures. Ces questions se limitent bien souvent à dresser un rapport entre le temps d'encodage et les possibilités d'exploitation souhaitées de cet encodage.
Pour autant, ces deux questions ne résolvent pas le problème de la structure générale du fichier, ce qu'on pourrait appeler les macro-structures. Dans ce cas, la question essentielle est : qu'est-ce-qu'on encode ? accompagnés d'une série de questions : quelle est la nature du document encodée ? Quel est le but poursuivi par l'encodage de ce document en XML ? Quel stratégie d'encodage je vais adopter ? Pour bien comprendre les enjeux de cette question, je vous propose deux exemples, un avec HTML et l'autre avec TEI.
Pendant des années, nous avons utilisé les tableaux HTML pour construire nos pages Web. Si on y réfléchit bien, ce principe, qui était dû à une mauvaise compréhension et prise en charge de CSS par les différents outils (éditeurs ou navigateurs), mais aussi à l'utilisation abusive de mauvais éditeurs WYSIWYG, revenait en réalité à encoder le graphisme et non la structure de la page Web en HTML. Dans ce cas, on ne se posait pas la question (d'ailleurs on ne se posait aucune question), le rendu final à l'écran constituait le but unique poursuivi.
Aujourd'hui, heureusement, les choses ont changé et on applique assez scrupuleusement la séparation de la mise en forme et du contenu, paradigme au cœur de XML. La structure du code HTML reflète (ou du moins est censé refléter) la structure d'une page Web. D'ailleurs, on pourrait tout à fait mettre en lumière un modèle pour toutes les pages Web, puisqu'elles sont en gros constituées de trois parties/divisions :
Un « cartouche » contenant les informations sur la page : nom du site, titre de la page..., bref, en quelque sorte les métadonnées, même si elles sont visibles ;
Un ou des menus de navigation qui sont en fait des listes de liens ;
Le contenu proprement dit de la page Web.
La construction du code source d'une page Web en HTML impose donc cette réflexion de base sur les stratégies d'encodage. Elle aurait d'ailleurs peut-être permis une prise de conscience plus tôt de ce qui apparaît aujourd'hui comme une évidence, à savoir l'utilisation de CSS pour le graphisme et la mise en forme de la page Web.
Cette question sur le but poursuivi par l'encodage se pose de façon encore plus criante dans l'utilisation de la TEI. Comprenant pas moins de 450 éléments, la TEI est, en outre, très générique. Il est donc possible d'encoder un même document de plusieurs manières différentes. Dans le cadre de mon travail à l'École des chartes, nous sommes amenés à encoder des textes de nature différente en TEI. Il serait pour nous inconcevables d'utiliser la même structure TEI pour encoder un inventaire de manuscrits, l'édition d'un manuscrit littéraire ou encore l'édition d'un chartrier (ensembles des actes, c'est à dire pour faire vite des papiers administratifs, d'une institution laïque ou ecclésiastique au Moyen Âge et à l'époque moderne).
D'ailleurs, revenons quelques instants sur les sources historiques. Dans ce cas, certains nous reprochent de ne pas assez travailler sur la source en elle-même. Mais, notre but n'est pas d'encoder la source, mais l'édition critique de la source qu'a mis au point le chercheur. Cela signifie que la structure du fichier TEI ne reflète pas la structure de la source ce qui dans nombreux cas est d'ailleurs pratiquement impossible à faire, mais la structure d'une édition de sources, c'est à dire non seulement le texte de la source transcrit, mais aussi ce qu'on appelle l'apparat critique : analyse du chercheur, notes de bas de page, collations (le fait d'indiquer les différences entre les copies manuscrites d'un même texte)... C'est pourquoi, je ne fais pas un fichier TEI par acte, c'est à dire par source, mais un fichier TEI pour l'ensemble de l'édition d'un chartrier, car cela correspond à un ensemble documentaire logique et au but poursuivi par l'encodage (et par la publication, d'ailleurs).
Alors, la prochaine fois que vous avez un problème pour encoder votre document XML, faire votre choix de balises en TEI par exemple, arrêtez-vous quelques instants, levez le nez de votre machine et demandez-vous : « Mais au fait qu'est-ce-que je suis en train d'encoder ? ». La réponse devrait vous mettre sur la voie.
Quelques notes en passant
1 Pour ceux qui ne suivent pas ou qui sont de nouveaux lecteurs de ce blog, la TEI, Text encoding initiative, est un guide de balisage mis au point par un consortium indépendant et servant à encoder en XML les textes issues de la recherche en sciences humaines ou à vocation littéraire. Si vous voulez en savoir plus, le mot-clef/tag TEI sur ce blog devrait vous renseigner.
Commentaires