4. Une collection de données numériques

L’exemple suivant illustre le cas de données numériques. Un index a donc été créé, mais chaque entrée était liée à un fichier CSVM plutôt qu’à un document texte (OpenOffice, XML, HTML, PDF…) ou à une source de données (fichier de données, image, hyperliens). Dans ce cas, les données CSVM (table de mesures, et non un index) sont issues d’un tableur standard.

Comme dans le cas précédent, les utilisateurs finaux peuvent télécharger les fichiers CSVM correspondants grâce à un hyperlien dans l’affichage de l’index, mais ils peuvent également consulter directement les tables de données grâce à un composant Javascript spécialisé qui utilise une table JavaScript après transformation de l’ilot CSVM. L’image suivante montre une table de données (toutes les colonnes ne sont pas affichées), en mode paginé, avec la possibilité de tri étendu sur les colonnes et de requêtes (bouton Query).

Dans cette table, l’information #WIDTH est utilisée pour définir la largeur des colonnes, et les valeurs #TYPE sont injectées comme noms de colonnes dans les tableaux JavaScript. Le CSVM peut être utilisé à la fois pour les index et pour les tableaux. Cette approche présente un fort potentiel pour le traitement complexe de fichiers auto-documentés, car un seul parseur et un seul format sont utilisés, indépendamment de la nature des objets tabulaires et des informations qu’ils contiennent.

5. Conclusion

Le composant JavaScript original (celui de Dieter Bunger) qui était utilisé dans la section précédente, a disparu de la toile, comme beaucoup d’autres codes. Je maintiens mes codes pour les index car ils me sont encore très utiles et ils résistent bien au temps. Aujourd’hui on peut faire les mêmes choses avec des composants JavaScript de type DataGrid éventuellement connectés avec une bibliothèque React (ou équivalent). Mais le principe est souvent le même : un objet JavaScript qui embarque une table JavaScript comme source de données, puis des fonctions plus ou moins riches qui sont chargées de l’affichage.

Ces exemples montrent ce que l’on peut arriver à faire (et depuis deux décennies) pour présenter des données, sous la forme de vues et sans faire appel à un SGBDR, ce qui est parfaitement connecté avec le paradigme CSVM. Nous pouvons aller assez loin sous réserve que l’on dispose de composants JavaScript métier (comme JMol) et que l’on soit capables d’intégrer l’ensemble à la sortie d’une chaine de production ou de publication. Les processus d’indexation basés sur la production de fichiers XML montrent aussi que l’on peut générer un hub de données, sur le tas.

Néanmoins, aujourd’hui je préfèrerais utiliser un CMS car il sera possible de profiter d’une bibliothèque d’extensions, y compris dans l’export vers un flux XML. Mais coté interface nous aurons moins de facilité pour inclure des composants métiers à l’intérieur des articles, même s’il y a quelques contournements possibles. C’est le désavantage de cette stratégie, qui concerne autant les CMS que les outils de cahiers de laboratoires électroniques, nous arrivons aux limites métier, il y a toujours quelque chose qui manque, pour une discipline donnée.

Mais sur le fond quelle que soit la méthode utilisée, le problème reste inchangé, l’art est dans la manière de rédiger les articles ou de présenter les données, de manière à optimiser le traitement possible en aval.