Skip to content

Le XML pour écrire du texte, l’EAD pour produire des données (avec du A. Swartz dedans)

04/11/2014

Le XML, c’est pourquoi faire ?

Je l’avais annoncé dans mon billet parlant du livre posthume et inachevé d’Aaron Swartz : Aaron Swartz insère dans son ouvrage une longue diatribe sur le langage XML (ou plutôt sur l’usage qui en est fait), qui m’a beaucoup donné à réfléchir.

Pour m’éviter une traduction, et pour vous faire grâce de l’anglais, je vais citer le passage en question en reprenant la traduction d’aka Reup (merci, grand merci à lui !).

Concernant la production/publication de données, Swartz dégomme le XML au profit du JSON.

C’est au chapitre 5 :

XML est probablement quelque chose comme le pire format pour échanger des données. Voilà pourquoi :

Les langages modernes de programmation ont largement établi des standards concernant les mêmes composants de structure interne des données : entiers, chaînes, listes, sommes de contrôle, etc. JSON les reconnaît et rend facile le partage de ces structures de données. Vous voulez partager le nombre 5 ? Écrivez simplement 5. La chaîne « foo » est simplement « foo ». Une liste des deux est simplement « [5, « foo »] » – et ainsi de suite.

C’est facile à écrire et à lire pour les humains, mais surtout, et c’est encore plus important, c’est automatique à écrire et à lire pour les ordinateurs. Dans la plupart des langages vous n’avez même pas besoin de penser au fait que vous utilisez JSON : vous demandez simplement à votre bibliothèque JSON de sérialiser une liste, et elle le fait. Vous lisez un fichier JSON, et pour votre programme c’est juste une structure normale de données.

XML, de son coté, ne supporte rien de tout ça. À la place, il pense en termes d’éléments avec des données textuelles, des instructions de programmation et des attributs, qui sont tous des chaînes. Publier des données en XML nécessite de comprendre comment faire rentrer au chausse-pied vos données internes dans un format spécifique, puis de vous assurer que vous l’avez décodé correctement. Encoder du XML est encore pire.

La raison principale pour laquelle XML est si mauvais pour échanger des données est qu’il n’a pas été conçu pour ça en premier lieu. C’était un format pour baliser des documents textuels ; écrire des annotations avec des instructions de formatage de diverses sortes, à la manière d’HTML. C’est pour ça qu’il fait la distinction entre données textuelles et données d’attribut – les données d’attributs sont des choses qui ne font pas partie du texte véritable, comme :

J’attends avec impatience une démonstration <font color="green">couronnée de succès</font>.

Le mot « green » est une annotation, pas une partie du texte, donc va dans un attribut. Tout ça passe par la fenêtre quand vous commencez à parler de données :

<personne age="5"> <nom>Robert Booker</nom> </personne>

Pourquoi « age » est un attribut, alors que « nom » est un élément ? C’est complètement arbitraire, parce que la distinction est absurde.

Je vous le refais avec mes mots :

  • XML n’est pas conçu pour publier des données. La preuve, il ne peut pas typer (ou caractériser) ce qu’il contient.
    Je vous confirme à titre personnel que pour manipuler des dates avec XML et XSL, c’est très pénible.
  • XML est conçu pour baliser des documents textuels, afin d’ajouter des annotations ou précisions distinctes du texte, permettant la mise en forme ou la sémantisation des termes ou expressions.
    Mise en forme :
    J’attends avec impatience une démonstration <font color="green">couronnée de succès</font>
    Sémantisation :
    La bataille d'Austerlitz fut gagnée par <persname normal="Bonaparte, Napoléon (1769-1821)">Napoléon</persname> le 2 décembre 1805.

Et moi et mes feuilles XSL ?

Ça fait des années que j’utilise du XML pour manipuler des données. Et ce pour une raison bien simple : il y a 10-12 ans, j’étais environné de fichiers XML (fichiers texte ou fichiers de données), j’ai donc appris à utiliser XSL (qui permet de faire énormément de choses), et je ne sais pas utiliser des langages de programmation exploitation des fichiers JSON. Non, même pas PHP #shameonme.

Et pourtant le PHP (ou bien d’autres langages) est beaucoup plus simple (et surtout moins verbeux) que le XSL.

Donc dans les mois et années à venir, je vais continuer à manipuler des données en XML, produites par moi ou par d’autres, juste parce qu’au moins, de cette manière je sais faire. Néanmoins, les remarques de Swartz m’interpellent violemment, d’autant que ça fait des années que je me dis que JavaScript et PHP, ça me serait bien utile aussi. J’y viendrai certainement. Un jour.

En attendant c’est bien pratique d’avoir XML+XSL sous la main. Et c’est (je pense) exactement le même genre de cause qui maintient l’EAD en vie.

EAD

Ce que dit Aaron Swartz des raisons d’être, et des lacunes, du XML m’amène à considérer que l’EAD a été construit avec du matériau solide, mais de mauvaises fondations.

Les origines de l’élaboration de l’EAD datent des années 1990 (dixit Wikipedia, je ne suis pas allé chercher bien loin). D’après Wikipedia, son objectif est de fournir « un format standard de données pour la description d’archives, comparable aux formats MARC utilisés pour les descriptions bibliographiques« .

Je le dirais différemment : l’EAD est né pour permettre de publier en ligne un équivalent des inventaires d’archives qui existaient avant l’ère Internet.

Le parallèle est le suivant :

  • Les bibliothèques sont parties de leurs fiches cartonnées, se sont demandées ce qu’il convenait d’en faire dans un ordinateur, et ont conçu MARC.
  • Les archivistes ont eux aussi pris ce qu’ils produisaient auparavant, c’est-à-dire des inventaires (livres reliés, plus ou moins épais), et ont conçu une manière de les mettre dans un format informatique.

L’EAD a un jeu de balises assez proche de la TEI : les archivistes ont repris la logique d’un vocabulaire XML de balisage de texte, et ont ajouté des balises sémantiques, c’est-à-dire des balises permettant de désigner de manière univoque des concepts propres au monde des archives : l’origine d’un fonds, le service versant, etc.

Pour en revenir à ce que Swartz nous dit de XML, effectivement il est possible en EAD d’insérer des balises paratextuelles à l’intérieur d’un texte :

Ce fonds contient des pièces relatives à <persname normal="Bonaparte, Napoléon (1769-1821)">Napoléon Bonaparte</persname>

Sauf que…

Quel est l’intérêt d’une telle utilisation de l’EAD ?

Dans un fichier textuel, un tel balisage peut servir par exemple à produire un index. Ainsi dans une thèse portant sur les Carolingiens, on aura des passages du genre :

<entry normal= »Charles II le Chauve (843-877) »>Charles le Chauve</entry> accorde alors au monastère […]. Et tandis qu’il lutte contre ses barons, <entry normal= »Charles II le Chauve (843-877) »>le roi</entry> envisage enfin de […].

Ce qui permet d’avoir dans l’index :

Charles II le Chauve (843-877) : 27, 75

Plus généralement, ces balises facilitent la recherche en texte intégral, en permettant de chercher sur des termes « cachés ».

Mais en EAD, pour une notice, à quelque niveau que ce soit, on peut ajouter des termes d’indexation (noms de personnes, termes géographiques, mots-clés).

Donc je ne vois pas ce qu’apporterait (en termes d’usages pour l’internaute) cet encodage :

<scropecontent><p>Ce fonds contient des pièces relatives à <persname normal="Bonaparte, Napoléon (1769-1821)">Napoléon Bonaparte</persname></p></scopecontent>

Par rapport à celui-ci :

<scropecontent><p>Ce fonds contient des pièces relatives à Napoléon Bonaparte</p></scopecontent>
<controlaccess><persname>Bonaparte, Napoléon (1769-1821)</persname></controlaccess>

Il y a 20 ans, il était tout à fait normal de concevoir un instrument de recherche dans sa cohérence globale, et souhaiter proposer pour sa version en ligne un système de navigation de type arborescent, comme un feuilletage dynamique au sein d’une table des matières dans laquelle on entre toujours plus profondément.

Mais aujourd’hui il me semble évident que pour signaler des fonds d’archives, ce qu’on fournit à l’internaute s’apparente bien davantage à des données structurées (avec une arborescence entre elles, je ne la conteste pas !) qu’à un document textuel structuré.

Conclusion : il faut continuer d’utiliser l’EAD

Aaron Swartz exprime son avis sur les 2 formats parallèles (ou opposés ?) JSON et XML à propos de la mise en place d’API, qui permet de diffuser des données structurées, comme alternative au site web « standard ». Pour ces API, il explique que le XML est à bannir parce que non adapté, alors que JSON est formidable pour plein de bonnes raisons.

L’EAD n’est pas utilisé dans un tel contexte. Actuellement, il sert

  • comme format de saisie dans les services d’archives et bibliothèques pour produire des inventaires de fonds d’archives et de manuscrits (Calames)
  • comme format d’export d’une application permettant de gérer des archives
    et comme format d’import pour les applications permettant de publier en ligne de tels inventaires (Pleade, ICA-AtoM, etc.)

A aucun moment il n’est utilisé comme format structuré de mise à disposition « brute » sur internet en alternative à la version web. On est donc dans des contextes différents de ceux qui intéressent Aaron Swartz.

Néanmoins il me semble qu’on peut retenir de son propos deux informations utiles :

  1. la raison d’être du XML (baliser des termes ou expressions pour enrichir les niveaux de sens ou la présentation, les deux pouvant se rejoindre)
  2. la non-adéquation du XML pour gérer des données

L’EAD est à présent bien implémenté dans toute une série de logiciels, pour archives, musées et bibliothèques. Je ne vois pas pourquoi on cesserait de s’en servir. On doit s’en servir pour les mêmes raisons que je continue de me servir de XSL pour manipuler des données XML que je produis moi-même.

Mais en ayant bien en tête qu’il s’agit là de données liées entre elles, pas d’un texte structuré.

Mais en se projetant dans la suite, car il ne faut pas en rester là.

Mais en l’utilisant comme format d’import ou d’export. Pas comme format de saisie.

12 commentaires
  1. Irnerius permalink
    04/11/2014 12:06

    J’avoue que je ne comprends pas. Les inventaires d’archives encodés en xml/EAD fonctionnent très bien, la saisie au quotidien se fait sans problème, la publication aussi, et il s’agit d’un progrès fabuleux par rapport aux inventaires papier ET aux inventaires juste mis en pdf sur internet. Quel est le problème ?

  2. 04/11/2014 13:36

    J’en étais arrivé à la même conclusion qu’Aaron Swartz quant au fait que XML avait été perverti. J’avais d’ailleurs écrit une série de billets sur la question : http://www.lespetitescases.net/carcans-de-la-pensee-hierarchique-et-documentaire-1 http://www.lespetitescases.net/carcans-de-la-pensee-hierarchique-et-documentaire-2 et http://www.lespetitescases.net/antilope-sur-le-Web-est-elle-un-document . Dans le second billet, j’abordais la question de l’EAD. Et je ne partage pas ta conclusion.

    Mais avant d’en donner les raisons, il faut au préalable séparer deux notions : le modèle et la syntaxe. Ce que remet en cause Aaron Swartz est XML en tant que syntaxe. En effet, cette syntaxe n’intègre pas de mécanismes simples de typage de données et c’est effectivement une difficulté pour traiter simplement des données, il faut en passer par un schéma qui donne la nature de la donnée, alors qu’en Json, c’est la manière d’inscrire la donnée qui permet d’en assurer le type. Or, en informatique (pour répondre à Irnerius) le typage est essentiel pour pouvoir appliquer facilement des traitements en fonction de la nature de la donnée (tu ne peux pas faire d’addition avec des chaînes de caractères pour donner un exemple trivial ou extraire l’année d’une date si cette dernière n’est pas écrite de manière normalisée pour reprendre l’exemple de Lully). Aaron Swartz explique cette absence en revenant au fondement même du format : encoder des documents textuels et il a tout à fait raison d’en revenir là, car au delà de l’explication sur le typage des données, cette origine explique aussi, comme je l’avais montré dans mes billets, le modèle XML à savoir l’organisation hiérarchique de l’information. Ce point n’est pas critiqué par Aaron Swartz puisqu’il en appelle à l’utilisation de Json qui est basé sur le même modèle.

    Or, c’est précisément sur ce point que se pose un problème pour l’EAD et la raison pour laquelle je diffère de ta conclusion. Si on part du principe, comme tu le fais, qu’un fichier EAD décrit un inventaire d’archive, soit un document textuel fini, l’EAD et le XML sont a prioi approprié (malgré tout, une petite API d’exposition avec du Json plutôt que de l’OAI-PMH serait quand même plus simple à exploiter… enfin ce que j’en dis….). Mais, conçoit-on encore la description archivistique comme un document textuel fini ? De moins en moins et on s’oriente de plus en plus vers de la donnée structurée et dans ce cas, on est en droit de se demander si le modèle XML est bien adapté. Je ne referai pas la démonstration ici des raisons et je te renvoie au second billet de la série dans lequel j’aborde ce point.

  3. 04/11/2014 14:27

    @Got : Apparemment je n’ai pas été super clair. Pour moi, il est évident qu’on ne peut plus concevoir un inventaire d’archives comme « un document textuel fini ».
    Il s’agit bien de données structurées — même si on met parfois du temps à s’en rendre compte, ou (ce qui est mon cas) si on met du temps à comprendre en quoi le XML n’est pas adapté pour traiter des données.

    J’avais déjà constaté, pour un certain nombre de sujets, que j’avais 4-5 ans de retard sur tes billets🙂 Donc c’est bon, je suis encore dans les temps !

  4. 04/11/2014 14:33

    @Got : Au temps pour moi, je me rends compte que mon titre est complètement paradoxal.
    Ce que je voulais dire, c’est que justement il y a contradiction entre l’objectif du XML (produire du texte) et l’objectif de l’EAD (produire des données).
    Donc la contradiction est dans la situation plus que dans mon titre. Mais le titre du billet n’aide pas forcément à comprendre ce que je veux dire (ce que je veux dire est : il faut espérer un jour qu’on arrêtera de vouloir produire des données avec de l’EAD, ce n’est pas approprié).

  5. Nicolas et Pimprenelle permalink
    05/11/2014 08:44

    Mais êtes-vous archivistes ? il existe encore beaucoup d’inventaires textuels d’archives « finis », qui restent à faire, à rédiger, pour des fonds papier traditionnels qui sont des fonds clos : il en reste des centaines de fonds clos non classés en France…. et avant l’xml/EAD, on n’avait que Word… no comment. Bravo pour la discussion quand même

  6. 05/11/2014 10:28

    @Nicolas et Pimprenelle : votre question rejoint un peu celle d’Irnerius. En gros : pourquoi je viens vous emmerder avec ces détails ? (si je résume)

    Une précision supplémentaire pour Nicolas et Pimprenelle : par « document textuel fini », il faut comprendre « document clos/fermé sur lui-même », et non document achevé. La problématique qui est soulignée là n’est pas de dire que tous les inventaires sont faits (achevés), mais qu’aujourd’hui, on ne doit plus considérer un inventaire comme fermé sur lui-même, il faut l’élaborer en relation avec toutes sortes d’autres données (à commencer par des données présentes dans d’autres inventaires, du même service d’archives ou d’un autre service).

    Ma démarche est la suivante :
    Aujourd’hui, si nous avions à nous interroger sur la bonne manière de mettre en ligne des inventaires, quel genre de format/outil/méthode inventerions-nous ?
    Les inventaires EAD sont directement héritiers des méthodes de travail pré-informatiques, et d’une certaine manière (conceptuelle) de penser l’information.
    Après 15-20 ans d’internet, se diffuse progressivement des habitudes différentes, une perception différente de ce que peut être et doit être l’information.
    Voyez du coté des livres : les premiers livres électroniques (et encore la majorité de ceux produits aujourd’hui) sont des textes écrits, fermés à une date donnée, et pour lesquels la rédaction n’évolue plus à partir de cette date-là. Mais d’autres formes d’écriture se mettent en place : à partir du moment où on écrit directement sur ordi, où on diffuse directement via internet, où on lit exclusivement sur écran, quel est le sens de cette « fermeture » chronologique d’un texte ? Pourquoi ne pourrait-on pas le déplier éternellement ?
    C’est le genre de réflexions qui naissent peu à peu, et font émerger une autre manière de créer dans l’environnement numérique.

    Pour en revenir à la question de départ : oui, l’EAD permet aujourd’hui d’encoder et de diffuser des inventaires d’archives.
    Mais dans un modèle de navigation datant des années 2000.
    Et la notion d’inventaire, à l’heure d’internet, pose même question. Ce qui importe, c’est de décrire des fonds d’archives d’une manière intellectuellement satisfaisante, afin d’en permettre l’accès et la gestion. L’inventaire n’est pas un objectif en soi. C’est le résultat d’une chaîne de traitement. Si une autre chaîne de traitement s’avère plus pertinente, pourquoi le refuser ?

    Pour ma part, avec le linked data, etc. on inventerait aujourd’hui autre chose que de l’EAD.

    Au fait, je ne suis pas archiviste. Mais je suis archiviste-paléographe. Ca compte ?
    Par ailleurs, j’ai régulièrement l’occasion de me préoccuper de la production d’inventaires d’archives en EAD, pour le portail européen des archives. Ca compte ?

  7. Poivre permalink
    05/11/2014 12:00

    Bonjour,

    Un mot au préalable pour me situer : je suis conservateur dans un service public d’archives et je pratique depuis longtemps l’encodage en XML-EAD.
    Je partage tout à fait l’avis d’Étienne Cavalié : XML n’est absolument pas adapté à la description de données. Mais j’irai plus loin, car je pense que l’EAD ne l’est pas non plus, précisément en raison de sa structure arborescente. Si données il y a ce sont celles contenues dans les balises et de fait leur manipulation est loin d’être simple.
    Donc, oui, il faut utiliser l’EAD pour mettre en ligne certains de nos « vieux » inventaires, mais cela ne doit pas nous empêcher de réfléchir à d’autres outils mieux adaptés, à la fois à la nature des fonds décrits, et aux usages actuels des internautes.
    Pour finir une question à l’hôte de ce blog : j’ai l’impression que le futur schéma EAD, actuellement en cours d’élaboration, est conçu pour permettre de décrire des données (avec notamment l’élimination du maximum de valeurs textuelles). Partagez-vous cet avis ?

  8. Jeux floraux permalink
    05/11/2014 13:49

    Certains dossiers d’archives, notamment les dossiers de principe ou juridiques, les archives de cabinet ministériel ou de décision, sont assez pointus et demandent une analyse réellement littéraire de 5 lignes. Il y a bien quelques données là-dedans (dates extrêmes, lieux etc. ) mais on ne peut supprimer la partie « littéraire » de la description archivistique, elle est essentielle. Pour cela, l’xml/EAD convenait si bien à l’archiviste….

  9. 05/11/2014 14:10

    @Jeux Floraux : une zone de texte libre, littéraire, me paraît une chose applicable hors de tout XML.
    Mais rassurez-vous, l’EAD est loin d’être terminé.
    Je suis sûr que quand une nouvelle solution satisfaisante émergera, elle sera conçue pour être compatible (conversion aisée) avec tous les inventaires EAD pré-existants🙂

  10. 06/11/2014 20:39

    Pour la clarté de lecture, je signale que Irnerius, « Nicolas et Pimprenelle », et « Jeux Floraux » émanent du même commentateur.

Trackbacks

  1. Le XML pour écrire du texte, l’EAD...
  2. Le XML pour écrire du texte, l'EAD pour ...

Les commentaires sont fermés.

%d blogueurs aiment cette page :