5. Langages et extensions

L’interface CSVM-Langage peut être comprise en trois couches principales, du bas vers le haut :

	La couche applicative, qui exploite ensuite cet objet CSVM.
	L’API CSVM, utilisée pour lire le fichier et le convertir en un objet CSVM intégrant une matrice de données, il s’agit du parseur CSVM.
	Le fichier CSVM lui-même, qui contient les données et les métadonnées.

Des parseurs ont été développés en Perl (preuve de concept) et en Python (opérationnel et extensions) sur la base de bibliothèques de composants logiciels (build puis buildez).

9. Conclusion

Le CSVM ne se veut pas un substitut des formats conçus pour la gestion de masses de données (tels que HDF5 ou NetCDF), ni de l’XML ou JSON. Il se distingue par sa focalisation sur les données tabulaires et par la possibilité d’utiliser un parseur unique pour traiter différents types de données.

Il s’agit d’un format qui doit rester léger, destiné à gérer la complexité des ilots de données qui jalonnent la pratique scientifique dans beaucoup de disciplines. Au fil de l’eau des preuves de concept ont été développées pour étendre la fonctionnalité du format, portant sur plusieurs axes :

• Transformations – Les dictionnaires CSVM permettent d’implémenter des modification d’une table : changements de nom de colonnes, de type (au sens CSVM),  suppressions de colonnes … et pour plusieurs jeux de transformations. Une opération sans code complexe puisque la table est confrontée au dictionnaire en une seule instruction, la transformation est indépendante d’un effort de programmation. Un peu comme si nous avions un masque pour une sorte d’opération algébrique sur la table CSVM. Ces ensembles sont encodés dans un même dictionnaire, par exemple nous pouvons avoir deux jeux de transformations ‘FR‘ et ‘EN‘ qui peuvent servir à traduire les noms de colonnes d’une table CSVM. Une fonction de l’API CSVM qui est opérationnelle dès sa conception et qui s’applique aux fichiers CSVM et CSV.
• Annotations – Aujourd’hui le format peut être annoté sans structure particulière. Par exemple un fichier CSVM peut être annoté dans toutes les positions (sauf après le bloc de métadonnées), des commentaires peuvent être intégrés dans la table de données, portant sur une ou un bloc de lignes. Des informations qui ne sont ni des données, ni des métadonnées (par exemple des paramètres expérimentaux, la description d’un modèle numérique ayant produit les données …) et qui vont accompagner l’ilot de données d’une manière cohérente et conservée. En effet l’extension au niveau parseur, permet de lire ces annotations, de les intégrer dans l’objet en mémoire, de les sauvegarder dans une nouveau fichier. Cette extension est opérationnelle post 2020.
• Encapsulation – L’idée est d’intégrer des images, ou tout type de texte, via un encodage (exemple base64) ou non, dans une table CSVM. L’idée est simple, des pointeurs sont présents dans la table CSVM, qui permettent de reconnaitre des zones encapsulée après le bloc de métadonnées. Cette partie est basée sur un le paquetage buildez.emb (opérationnel poste 2000) qui permet de faire le même type d’opérations dans un fichier ASCII libre. Une conséquence de cette approche est de pouvoir également encapsuler des tables CSVM filles, dans des cellules d’une table CSVM parente, sur un nombre de niveaux limités (profondeur) mais théoriquement indéfini. Ce qui ouvre un niveau permettant une certaine récursivité, mais casse une partie du paradigme CSVM puisque nous sortons d’une table de données entièrement en mode string pour intégrer quelques objets csvm_ptr dans les cellules. Il s’agit d’une preuve de concept, à finalité expérimentale.

D’autres extensions sont prévues, si elles ont une utilité au sein d’un laboratoire, par exemple des cellules multi valeurs dans une table. Le développement d’un mini parseur CSVM, sans les extensions du parseur standard et indépendant de l’API CSVM est également en cours de développement.