Il existe typiquement trois modèles différents, divisés en deux catégories, de fabrication de contenu texte dirigé vers l’édition:
- Le modèle appplicatif qui se présente sous deux formes possibles: l’application CLIENT et l’application WEB.
Dans les deux cas, la numérisation des données en entrée est pensée pour être le plus transformable possible, pour pouvoir jouer avec les options de création de contenu et produire les formats attendus ou à venir pour répondre à un ou des besoins spécifiques. Dans la plupart des cas personne ne se soucie de la façon dont les contenus sont créés. L’accent est mis sur la finesse et l’évolutivité de la création et de ses outils. Seuls importent ensuite les formats de sortie, non plus pour création mais pour diffusion, exploitation, conservation. Savez-vous comment sont numérisés les contenus dans Indesign ou QuarkXPress? Non, et cela ne vous pose aucun problème.
- Vient ensuite le modèle “chaîne” de formats” avec par exemple la plate-forme CybersDocs, pour la publication des thèses en ligne, ou O’Reilly avec son schéma XML Docbook.Selon ce modèle, un format produit pour répondre à un besoin sert de base pour la production d’un autre format destiné à répondre à un autre besoin. La chaîne implique que les transformations vont se suivre les unes après les autres.
Devant la recrudescence des discours encensant les “chaînes XML” nous voulons nous arrêter sur la différence logique qui sépare ces deux approches et inciter à retourner vers le modèle applicatif.
Deux idées erronées, qui n’en sont qu’une, poussent à se tourner vers le modèle de la chaîne XML:
- La première idée est qu’un format est séparable du processus auquel il appartient: In, Out et média/ outils associés.
- La seconde consiste à penser que le passage d’un format à un autre (modèle chaîne) ne représente pas une perte dans le processus d’édition, de diffusion et d’exploitation des contenus édités. Le corollaire étant qu’il existe un BON format (global, universel, intemporel) en entrée pour toutes les sorties.
Exemple de la chaîne CyberDocs
Prenons comme exemple la chaîne CyberDocs, plate-forme de conversion principalement maintenue à travers le projet Cyberthèses:
Le module de conversion de la plate-forme Cyberdocs vise à automatiser un processus de conversion depuis un format traitement de texte vers un document structuré en format XML, selon la DTD TEI Lite. Une telle opération consiste donc à identifier le plus de structure possible dans le document original pour rendre le document XML le plus riche possible.
[...]
Le module de conversion de la plate-forme Cyberdocs ne se contente pas de produire ce
document XML de référence. En effet, une fois celui-ci obtenu, le module peut produire des versions du document prêt à une publication statique, en format HTML, XHTML ou PDF. De plus, le module va préparer un ensemble de documents qui alimenteront le module de publication pour rendre l’interface de consultation encore plus riche.(Documentation PDF, p.26)
Les objectifs:
- production d’un document sémantiquement structuré pour un archivage pérenne (TEI Lite),
- publication “statique” (HTML, XHTML, PDF)
- recherches documentaires précises à l’intérieur d’un document ou dans une collection de documents publiés.
Le IN: dans ce processus est déterminé par la production des auteurs dans leur logiciel bureautique de traitement de texte, par une habitude, ce qui est parfaitement légitime. C’est la contrainte de départ, du ODT.
Un OUT primaire:
- TEI Lite comme format sémantiquement structuré, pour archivage pérenne (dont on sous-entend par ailleurs qu’il serait “dynamique”).
Les OUTs secondaires (issus de TEI Lite):
- Fiche de métadonnées,
- HTML statique destiné à l’affichage en flux et à produire un fichier Html de transport.
- PDF destiné à l’impression.
Analyse de la chaîne CyberDocs
Nous avons plusieurs chaînes du type: ODT-> TEI Lite -> Format X (Html, PDF, XML métadonnées)
- 1ère étape: passage ODT-TEI Lite
- la feuille de style qui prépare le document ODT à cette transformation exclut de l’importation un certain nombre d’éléments: maths, dessins, graphiques, xlink, formulaires…
- la présence de cette feuille de style implique que l’on ne peut importer du ODT dans cette chaîne QUE s’il a été structuré à cette fin, il ne s’agit plus d’une importation de ODT comme format de “traitement de texte” mais uniquement comme format “ODT destiné à être validé en tant que TEI Lite”. Si votre thèse n’a pas été produite avec cette feuille de style son importation demandera un travail de préparation important.
Cette première étape, qui pallie à l’absence de structuration sémantique “littéraire” pour laquelle ODT n’est pas fait, impose donc une perte en universalité du processus.
- 2nde étape: Passage TEI Lite-Html et TEI Lite-PDF
Le document “XML de référence”, l’axe de la chaîne est TEI Lite, un schéma XML (vocabulaire et grammaire) développé pour l’échange des données textuelles, notamment pour les sciences humaines et les études sur les textes littéraires. Du fait de son orientation “structuration sémantique” et de son mode de production hors ligne il convient à la production de documents statiques de stockage et d’interrogation ainsi que de fiches de métadonnées riches.
C’est à partir de ce document que CyberDocs cherche à produire du HTML et du PDF, à répondre aux besoins “affichage et diffusion en flux dynamique en réseau” et “structuration typographique destinée à l’impression”. C’est oublier que TEI Lite répond déjà à une intention précise et est presque la fin d’un processus, que nous appellerons “structuration littéraire concertée pour échange de données textuelles”. Cela revient à vouloir utiliser le OUT d’un processus comme IN dans des processus qui ne lui correspondent pas et qu’en conséquence il appauvrit.
La structure TEI Lite permet de répondre en partie aux besoins de ces deux processus. CyberDocs produit bel et bien des thèses en Html (statique, enfermé dans des cadres (frameset), peu ou pas accessible aux handicapés ou aux moteurs de recherche) et en Pdf (et pourrait en produire des versions plus riches à partir de la TEI native) .
En partant de TEI Lite statique CyberDocs renonce cependant à la part collaborative du Html puisque les contenus de production ne sont ni en ligne ni associés à des outils pouvant les rendre dynamiques. Cet aspect du Web n’est sans doute pas un argument de taille pour les universités et les chercheurs dont le travail tient encore à rester “encapsulé” avant publication officielle. Mais CyberDocs renonce également à l’intégration des contenus au Web pour une exploitation raffinée des connaissances après publication (Web services). À l’exception du catalogage et de la publication de fiches de métadonnées (localisation) les contenus ne peuvent être extraits et/ou réutilisés de façon dynamique dans d’autres ouvrages, analyses, hyper indexations, etc.
Conclusion
La première étape de la chaîne nous fait perdre en universalité, la seconde en fonctionnalités.
Qu’est ce qui même au choix d’une telle chaîne de formats?
- L’idée d’un format ad hoc
- TEI, TEI Lite, Docbook sont des formats de stockage et d’interrogation exprimant chacun des besoins spécifiques…,
- ODT pour une lecture sur un bureau et sa qualité de traitement de texte Wysiwyg en relation avec l’imprimante,
- HTML pour une présentation en flux…
- PDF pour une impression papier…
Cette pauvreté relative (perte de l’universalité de production des contenus et staticité de la sortie Web en particulier) est ici inévitable parce que l’on fait du résultat de l’objectif 1 (TEI Lite statique hors ligne) le IN des objectifs 2 et 3.
Ce choix provient de l’idée selon laquelle un format, et notamment le XML, est une information qui peut toujours être transformée. Or, un format, quel qu’il soit, est une réponse à un besoin. Il est engagé dans un processus qui a transformé les données…. C’est le vieux principe de McLuhan, “le message est le médium”. Il n’y a pas de transmission linéaire de l’information. D’ailleurs il n’y pas d’information au sens de message portant à lui seul un sens univoque et par conséquent compris par tous de la même façon quel que soit le contexte. Il faut donc dans un premier temps oublier cette quête quasi mystique du BON format (global, universel, intemporel).
Dans une chaîne il y a orientation à chaque étape, orientation irréversible. Cette orientation peut être de grande qualité dans un objectif donné:
Pour autant, faire un passage horizontal d’un format vers un autre fait toujours prendre le risque d’une perte, quoi qu’il en soit de la qualité de la feuille de transformation. La perte tient dans la négligence des différences d’objectif que sous-tendent chacun des formats, le processus auquel ils appartiennent et les outils qui y sont associés. Un format est toujours une réponse à un objectif. Ou plus exactement format et objectif fusionnent.
- La séparation format/processus
L’autre idée qu’il faut ici démonter est celle selon laquelle un format est séparable du processus auquel il appartient: In, Out, et média, outils associés.
Le XML est partout présenté comme LE format qui offre structuration sémantique, capacité de transformation illimitée vers une multitude d’autres formats, garant de la plus grande pérennité, et qui transporte donc toute l’information nécessaire sur un contenu donné pour son utilisation actuelle et future dans tous les contextes. N’en déplaise aux “experts”, c’est une erreur.
D’une part, le xml n’est pas un format. C’est un niveau de “numérisation” règlementé, un langage de balisage générique destiné à ranger des données textuelles, et dont le vocabulaire et la grammaire ne sont pas définis a priori. Lorsque l’on détermine des règles pour le balisage, des grammaires, celles-ci s’expriment en des schémas (DTDpar exemple), qui permettent notamment de valider automatiquement un document sur sa conformité à ce modèle. Le xml est une technique et c’est quand il est associé à un schéma qu’il devient un format! Donc, dire que le XML garantit pérennité, capacité de transformation universelle, revient à dire que l’encodage en O et 1 garantit pérennité, capacité de transformation, etc. Autant ne rien dire.
D’autre part lorsqu’il est associé à une DTD, et devient un format, le XML est déjà engagé dans un processus spécifique, une réponse à un besoin, lié à des outils (scripts), à des modes de présentation (supports de lecture) et pour lequel cette DTD a été élaborée. Il ne peut plus (ni ne dois) dès lors être appelé à répondre à tous les besoins.
Comme pour les autres formats (non xml), pas plus TEI que Docbook, xhtml, mathml, svg, etc, ne peuvent répondre à tous les besoins. Aucun d’entre eux ne peut constituer un bon IN pour tous les autres processus d’édition: Web, papier, eBook, Mobile…
Comment sortir alors de cette recherche du format ad hoc, répondre au besoin de pérennité et à la peur de la multiplication des sorties?
Revenir à la logique applicative:
- mieux regarder l’ensemble des composants, outils de fabrication, formats d’exploitations, d’utilisations, et ainsi penser en terme de processus et non pas d’objet,
- s’assurer de la finesse et de l’évolutivité des outils de création: pour cela ne pas chercher un format de données “brutes” normé mais au contraire hybridable avec d’autres techniques (comme LaTeX et XML) qui créent une donnée “brute” la plus transformable possible. Déhiérarchiser les processus d’édition.
- à partir de cette donnée transformable, non normée, penser publication en étoile, chaque branche correspondant à un processus (une intention) donné.Il ne faut pas d’axe majeur, de “format de référence”.
- s’assurer de l’accessibilité, de l’ouverture des formats et langages utilisés afin qu’ils puissent évoluer en fonction des nouveaux besoins, machines, lecteurs…
- ne pas oublier que tous les OUT/exploitation/supports de lecture à venir ne peuvent être prévus.
__________________
Schéma (image cliquable pour une meilleure lecture) : Édition numérique à partir d’une application Web comparée à une “chaîne de formats”.
