CSV Validator, le XML du pauvre ?

Les Archives Anglaises ont défini un format  pour faciliter la récupération d’informations à archiver depuis une application source.

Le constat était simple : « it was recognised that it was too difficult and/or expensive for many suppliers to produce the desired metadata in XML »

Le format CSV, quant à lui, est un bon candidat, car facile à générer. En revanche, il est trop laxiste et trop limité.

D’où la notion d’un fichier CSV (ce n’est donc pas un nouveau format) qui suivrait un « schéma CSV » permettant de définir des règles de formattage.
Un schéma CSV permettra par exemple de :

  • Définir des informations générales que doit respecter le fichier (séparateur de colonnes, nombre de colonnes)
  • Indiquer le type de colonne : entier, date, chaîne…
  • Indiquer une contrainte plus forte sur le contenu d’une colonne : liste de valeurs autorisées, expression régulière, nombre de caractères,chemin de fichier valide…

« CSV validator » est l’outil qui valide un fichier .csv par rapport à un schéma CSV. Il sort une log d’erreur si une règle n’est pas respectée.

Ce fichier schéma CSV (extension .csvs) est,fichier texte ayant une syntaxe relativement simple pour exprimer les règles que le fichier CSV doit suivre.

Par exemple, le schéma (csv avec 3 colonnes : un nom, un age et le genre) :

version 1.0
@separator ‘;’
@totalColumns 3
name: notEmpty
age: range(0, 120)
gender: is(« m ») or is(« f ») or is(« t ») or is(« n »)

L’utilisation de ce format pour l’archivage est effectivement à étudier. Bien qu’il soit préférable de gérer du XML, le CSV Validator pourrait être une solution alternative intéressante. Mais plutôt que d’archiver directement ce fichier CSV (dans ce cas avec son fichier .csvs), il serait plus intéressant d’avoir un préprocesseur en entrée du système d’archivage qui prendrait ces fichiers CSV et les transformerait en fichiers XML.

 

PS : cet outil fait partie de la liste des outils Open Source identifiés par le NARA (The U.S. National Archives and Records Administration) dans le document Open Source Tools for Records Management Report de mars 2015

Archivage d’un email : oui, mais quel format ?

Nous avons vu dans un précédent article la nécessité d’archiver les emails engageants.

Il s’agit maintenant d’identifier le format adapté à l’archivage pour ces emails.

Existe-t-il « un » format  d’archivage pour les emails ?

Cet article, sans être trop technique, se focalise sur le format proprement dit. De manière générale, pour qu’un format soit candidat à l’archivage, il est recommandé de s’appuyer sur un format pérenne, ouvert, normalisé, fidèle…

J’élimine donc tout de suite, les fonctions « d’archivage’ proposées par les clients de messagerie, trop propriétaires (format base PST ou similaire).

Un email est un objet complexe composé d’informations structurées (émetteur, destinataires, date, objet) et non structurées (le corps du message plus ou moins complexe et les différentes pièces jointes). Les formats sont normalisés au travers de RFC (Request For Comments) gérées par l’IETF : la partie structurée d’un email dans la RCF 2822 et des extensions pour gérer notamment les pièces jointes de différents formats (notion de type MIME) dans les RFC 2045, RFC 2046, RFC 2047, RFC 2048 et RFC 2049.

Les principaux formats rencontrés sont :

  • .msg (format Outlook) est un format propriétaire Microsoft dont les spécifications sont publiques. Il se base sur le principe d’un document composite englobant les différentes pièces jointes.
  • .eml, équivalent à un .mht, est un format texte avec les pièces jointes encodées dans le format Base64. Cet encodage ne pose pas de problème particulier car la table de conversion est publique. mais au final, on récupère les PJ dans leurs formats d’origine qui peuvent être propriétaires (Office par exemple)
  • MBOX (http://tools.ietf.org/html/rfc4155) et ses variantes.

Aucun de ces formats ne remplit les critères pour être archivé mais il est techniquement faisable de les transformer dans un format standard bien qu’un tel format n’existe pas. XML est bien adapté pour représenter la partie structurée d’un email et de nombreux projets ont vu le jour (XMTP, draft IETF, projet XMaiL) sans qu’aucun n’ait vraiment percé…

La gestion XML ne traite que la partie structurée d’un email. Il est donc important de ne pas oublier de traiter les pièces jointes en les transformant dans le « bon » format (PDF/A-2 pour la bureautique par exemple).

Concrètement, l’archivage d’un email demande un traitement à la source des emails identifiés comme étant à archiver. Il est conseillé d’archiver le mail source ainsi qu’une représentation de cet email (format XML du mail et transformation des pièces jointes dans un format pérenne).

Archivage d’une base de données : intérêt du format SIARD ?

Je risque d’être un peu provocateur mais la première question est de revenir au besoin. En effet, archiver une base de données ne veut pas dire grand-chose. Autant le contenu d’un document bureautique est compréhensible par un humain (à condition de disposer du bon lecteur évidemment), autant le contenu d’une base de données ne représente que des datas élémentaires. Et archiver une donnée sans son contexte n’a pas d’intérêt.

Si j’ai la valeur 100 dans la base il faut que je sache si cela représente 100€ ou 100k€ ou 100°C, que je connaisse ce que cela représente (un montant de facture, une température…) et son environnement (facture n° 123 du client ABC…, température maximale supportée par le composant X).

Il est donc souvent nécessaire de revenir à l’application au dessus de cette base de données pour analyser le besoin d’archivage. Et la solution sera différente suivant le besoin.

Je mets de côté le besoin IT de faire « maigrir » une application en enlevant des données pour avoir des meilleures performances. Je ne considère pas cela comme de l’archivage pur. La solution passe alors par des mécanismes internes offerts par le système de gestion de la base de données.

La solution, très lourde, consistant à conserver l’environnement complet (ordinateur, logiciels…) est à éviter mais certains contextes n’offrent pas d’autre alternative.

Voici quelques exemples de besoins :

  • Paie : je n’ai pas besoin d’archiver la base de données de la paie. En revanche, je dois archiver les bulletins de salaire. On revient à la problématique de l’archivage du document (papier ou électronique)
  • Données métiers (base interne) : données d’observation, données de modélisation d’un système…
    Il est nécessaire d’identifier une représentation externe de cette information et fournir le moyen de ‘relire’ le contenu. Plus le modèle de données est compliqué, plus la fonction de relecture le sera également. La tâche est encore plus compliquée si l’application au dessus de la base de données fournit des fonctions de calculs, agrégation… Dans ce cas, il faut également conserver les concepts et algorithmes permettant de manipuler les données.
  • PLM (Product Lifecycle Management). Ces applications permettent de gérer en configuration des produits (voiture, train, téléphone) tout au long de leur vie. Un tel système repose sur un modèle de données complexes (nomenclature) souvent propriétaire (pouvant comporter des centaines de ‘tables’), des millions de documents (des plans, des documents techniques…)
    La norme ISO STEP (STandard for the Exchange of Product model data) peut apporter quelques éléments de réponse mais cela nécessite une investigation poussée. Il arrive donc souvent que les données soient conservées en ligne…

Sur la problématique technique, les Archives Fédérales Suisses (AFS) ont défini un format standard SIARD (Software Independent Archiving of Relational Database) qui est un format de fichier ouvert pour l’archivage des contenus de bases de données relationnelles (utilisation du XML pour avoir une représentation générique du modèle de données avec typage des informations, gestion des relations ce qui est un plus important par rapport à un export brut en CSV). De plus, l’outillage (SIARD Suite) est également offert pour convertir une base de données relationnelle dans le format SIARD (et fonction inverse d’import pour pouvoir utiliser la puissance des requêtes SQL).

Le CINES (Centre informatique National de l’Enseignement Supérieur) a publié un intéressant guide (V1.1 du 16 avril 2013) autour de la problématique de l’archivage d’une base de données. Il pose notamment de bonnes questions sur la démarche à suivre, les avantages et inconvénients de différents formats candidats (Dump, CSV, XML, SIARD).

Pour conclure, SIARD est une approche à étudier lorsqu’on souhaite exporter des données d’une base de données ayant un modèle de données relativement simple (ou facilement compréhensible). Mais la clé est d’analyser le besoin initial pour identifier quoi archiver et quand…

PS : SIARD version 1.0 est approuvé depuis le 21.03.2013 par eCH sous la référence eCH-0165.

eCH :

développe et adopte des normes de cyberadministration, des solutions type, et des documents auxiliaires [au niveau de la Suisse]. Les normes ont valeur de recommandations et sont mises à disposition gratuitement