Les petites cases

En quoi la TEI constitue aujourd'hui une bonne solution ?

Parmi les grammaires XML existantes, il en existe trois qui se détachent pour encoder des textes : Docbook mis au point par Norm Walsh dont le but est d'encoder les manuels techniques, XHTML 2 (eh ! oui) qui me semble une solution simple et efficace, améliorant les défauts de hiérarchisation de l'information que présentait HTML puis XHTML 1 et TEI dont la vocation initiale est d'encoder les textes en sciences humaines et en littérature entre autres. Je mets de côté Open XML et Open Document qui sont les grammaires utilisées respectivement par Microsoft Office et Open Office dont le but ne me semble pas exactement le même que celles citées précédemment.

A la différence des deux autres, TEI occupe une place à part de par sa nature et son fonctionnement, en particulier avec la nouvelle version dite P5 qui ouvre des perspectives très importantes et pourraient bien réconcilier un certain nombre de communautés qui, pour des raisons diverses, bonnes ou mauvaises, ne l'utilisaient pas. En expliquant justement ce qui fait la particularité de TEI et les nouvelles possibilités de P5, je voudrais montrer en quoi elle constitue aujourd'hui une bonne solution et répondre ainsi à la question qu'on me pose souvent : pourquoi devrais-je choisir la TEI ?

La TEI : guide, schéma, DTD ou usine à gaz ?

Le but de la TEI n'est absolument pas hégémonique, le consortium, qui en a la charge depuis 1987, composé de chercheurs et de bibliothécaires du monde entier ne gagne rien si le nombre d'utilisateurs augmente. Son but est plutôt d'offrir des solutions efficaces pour répondre aux besoins d'encodage de l'information en vue de son exploitation bien-sûr, mais surtout en vue de son échange et de son partage. Je ne vais pas expliquer les avantages d'un standard dans ce cas, il me semble que vous en êtes tous conscients.

Dans mon premier billet sur la TEI, j'ai expliqué en quoi elle ne constituait pas une DTD en tant que tel, mais un framework. C'est plus que jamais le cas avec cette nouvelle version. Le processus de mise en place de la TEI n'y est pas étranger. Le schéma XML (quelque soit le format utilisé pour le décrire : DTD, XML schema ou RelaxNG) n'est qu'une conséquence du guide proposé par le consortium qui s'attache à définir, repérer et donc normaliser les différentes informations sur lesquelles se rejoint une communauté suffisamment importante d'utilisateurs. Vu les problématiques concernées par la TEI, il n'est pas étonnant de se retrouver avec plus de 450 éléments et c'est là que le bat blesse.

Le problème se pose alors aussi bien pour les concepteurs de la TEI que pour les utilisateurs : comment maintenir une telle librairie de plus de 400 éléments ? Comment apprendre et s'approprier la TEI ? Est-ce-que la TEI n'est pas une énorme usine à gaz ? Même avec ces 450 éléments, la TEI ne comprend pas la balise que je cherche, j'en veux pas.... Bref, il est évident que nous sommes face à un outil puissant, assez complet, mais difficile à prendre en main, fruit de compromis entre différentes personnes dans une communauté et même différentes communautés. Heureusement, le consortium TEI a pris les choses en main, en inventant un format pour décrire sa propre grammaire issue de la TEI appelé ODD (One document does it all) et l'outil pour générer une DTD; un XML schema et/ou un schéma RelaxNG à partir de ce fichier : Roma. Avec ces deux outils, la TEI mérite plus que jamais son appellation de framework.

Vous avez dit bizarre1, non j'ai dit 'ODD'

Dans la précédente version, la TEI proposait le modèle de la pizza pour construire une DTD issue de TEI. Le modèle s'appuyait sur le classement des différents éléments de la TEI en trois groupes : un module-noyau (« core tagset »), différents modules de base (« base tagset ») et différents modules additionnels (« additional tagset »), répondant à des besoins particuliers comme l'encodage de transcriptions de corpus oraux, l'encodage de dictionnaires ou encore d'apparat critique pour ne donner que quelques exemples1. Dans ce modèle, il était possible de retenir un ou plusieurs modules en plus du core et d'un module de base. Par ailleurs, une DTD dite TEILite rassemblant tous les éléments de base pour encoder un texte était mise à la disposition des utilisateurs. Dans ce modèle, ce n'était donc pas les ingrédients de la pizza que vous choisissiez, mais les ingrédients des différentes parts.

La nouvelle version abandonne le système de la pizza, mais conserve les systèmes de modules, en y ajoutant en plus la notion de classes d'éléments. Ces classes renvoient au comportement de l'élément dans votre grammaire : où je peux placer mon élément ? quels attributs sont disponibles pour cet élément ? Un élément peut appartenir à une ou plusieurs classes. Grâce au format ODD qui est en fait un fichier XML utilisant une grammaire dérivée de la TEI, vous allez alors pouvoir choisir les modules que vous voulez utiliser, mais en plus vous allez pouvoir :

  1. changer le nom d'un élément (le traduire en français par exemple, personnellement je suis contre cette pratique, mais chacun fait comme il veut) ;

  2. supprimer les éléments qui ne vous intéressent pas ;

  3. changer le comportement d'un élément, c'est à dire le changer de classes ;

  4. Ajouter un attribut et le rattacher à une classe ;

  5. ajouter un nouvel élément en le reliant à une classe, un module et/ou même un élément ;

  6. contraindre la valeur d'un attributs ou d'un élément.

Bref, vous allez construire votre grammaire XML adaptée à vos besoins, en vous appuyant sur la TEI, et tous les changements par rapport à la « TEI canonique », c'est à dire les éléments et les attributs, leurs noms, leurs comportements et leurs sémantiques décrits dans le guide, seront indiqués dans ce fichier ODD. Cerise sur le gâteau, ODD vous permet aussi de fournir la sémantique de chaque élément de votre grammaire à partir duquel vous pouvez générer une documentation complète. Pour les hard-coders, il est possible d'écrire directement son fichier ODD en XML, la documentation est disponible, mais je vous rassure, il est possible de le faire avec Roma, une interface en ligne user-friendly (il reste encore des améliorations à apporter, mais c'est de mieux en mieux) qui vous permettra aussi de générer à partir d'un fichier ODD ou de votre « customisation en ligne » un schéma dans votre syntaxe préféré : DTD, XML schema ou RelaxNG. Évidemment, RelaxNG offre plus de possibilités de contraintes, en particulier sur les valeurs.

Quid de l'interopérabilité avec ODD ?

Mais, j'entends déjà la question qui vous taraude : « c'est bien joli, c'est très souple, mais quid de l'interopérabilité ? ». Question légitime, que je me suis d'ailleurs posé. En fait, cette question se situe à trois niveaux. Au niveau d'une communauté précise d'utilisateurs partageant le même type de textes et les mêmes besoins, ODD va permettre de fixer le schéma de façon encore plus précise, répondant à des besoins spécifiques et surtout de le documenter.

Plaçons-nous maintenant au niveau de la communauté des utilisateurs de TEI, dans ce cas, il faut en revenir à la TEI telle qu'elle est décrite dans le guide. Or, le fichier ODD comprend toutes les spécifications de votre grammaire et les modifications par rapport à la « TEI canonique ». Ainsi, si vous avez ajouté un élément, vous l'aurez rattaché à un des éléments génériques de la TEI et il sera même possible de faire référence à une règle de transformation dans un fichier XSL cité dans le fichier ODD. Bref, dans ce cas, tout est la disposition pour migrer le fichier encodé selon cette grammaire vers un fichier « canoniquement valide » avec la TEI qui devient un format pivot d'échanges permettant la mise en place d'outils qu'on pourra partager. Enfin, même si certains éléments ont été changés, il existe quand même de grandes chances que les éléments décrivant la structure globale (les éléments de macro-structures) soit toujours les mêmes. Dans ce cas, l'interopérabilité n'est pas garantie à 100%, mais vous pourrez au moins travailler sur la structure générale du texte encodé.

Avec la mise en place de ODD et de Roma, la TEI se révèle encore plus proche des besoins des utilisateurs et se positionne comme une solution incontournable pour l'encodage de textes. Elle fait montre d'une maturité dont peu de schémas XML peuvent se vanter. Avec le précédent billet sur l'encodage, j'espère que vous êtes maintenant « armés » pour faire vos choix.

Quelques ressources pour finir

Si vous voulez en savoir plus sur ODD, quelques ressources (en anglais exclusivement) :

  1. Lou Burnard, One document does it all, diaporama sur ODD

  2. Lou Burnard et Sebastian Rahtz, Relax NG with son of ODD, Extreme Markup Languages 2004, Montréal, Québec, 2-6 août 2004.

  3. Syd Bauman et Julia Flanders, Odd customizations, idem.

  4. Laurent Romary, Uncovering the TEI and ODD, a pedagogical strip-tease, diaporama ppt.

Quelques notes en passant

1 Pour mes lecteurs non anglophones, ODD est l'acronyme de Document does it all dans le cadre de la TEI mais le mot signifie aussi bizarre en anglais.

1 Si vous voulez en savoir plus, cf le billet cité plus haut : la modularité de la TEI.

Structuration Causeries TEI XHTML —