Harmonisation format CSV

[Jeremy-Gaillard]

Bonjour,

Je constate des différences de formatage CSV entre différents schémas. Par exemple :

• https://schema.data.gouv.fr/etalab/schema-stationnement-cyclable/1.1.1/ utilise le séparateur ","
• https://schema.data.gouv.fr/NaturalSolutions/schema-arbre/ utilise le séparateur ";"

Y a-t-il une raison pour ces différences ? Ça me semble une source d'erreurs et de complications pour la création et lecture de ces fichiers (problèmes d’échappement de caractères, nombre à virgules, etc. à traiter différemment).

[johanricher]

Bonjour, les schémas que vous mentionnez sont écrits avec le format Table Schema, or celui-ci n'a pas de notion de séparateur puisqu'il travaille sur des données tabulaires et pas que des CSV. Un fichier sera valide s'il respecte le schéma, quel que soit le séparateur utilisé et même quel que soit son format tant qu'il est supporté (.csv, .xlsx, .xls, .ods...).

Une discussion, qui n'a pas tranché ce sujet, a lieu ici : etalab/guides.etalab.gouv.fr#117

Pour ma part je pense que normaliser la façon dont les CSV sont publiés n'a pas de sens et que les différences (séparateur, dialecte, encodage...) continueront toujours à exister. Les outils sont conçus pour que, du point de vue utilisateur, ces différences ne posent pas de problèmes. Si problème, ou irritants il y a, il faut les identifier et les résoudre.

Pouvez-vous donner des exemples de scénario où de tels problèmes seraient bloquant pour des réutilisateurs des données ?

[Jeremy-Gaillard]

Merci pour ces ressources, je retrouve beaucoup de mes frustrations avec le format CSV dans ces discussions.

Le problème que je soulevais n'est effectivement pas un problème avec le schéma, mais avec la documentation associée. Vous faites bien de me corriger, car même si on ne respecte pas les préconisations de la documentation concernant le CSV, les données créées restent valident. Ce que je soulève est donc moins un problème technique qu'une question de cohérence de la documentation.

Par contre, je constate que Table Schema exprime une contrainte sur le séparateur décimal, ce qui veut dire qu'il faut faire preuve de précaution lorsqu'on produit certaines données pour être bien conforme avec le schéma.

Je confirme également qu'il n'y a rien de bloquant à ces différences de formatage CSV, juste des irritants. Je pense à la version française d'Excel qui ouvre difficilement les fichiers CSV s'ils n'ont pas un sépateur ; et le BOM UTF-8. Mais ces sujets ont déjà été bien développés dans l'autre ticket.

Au final, je pense toujours qu'il est souhaitable d'harmoniser le paragraphe mentionnant le formatage du CSV, ne serait-ce que pour éviter la confusion. Ou supprimer le passage. Ou faire un renvoi vers la page du guide Etalab.

[geoffreyaldebert]

Bonjour Jeremy,

Vous avez raison, il vaut mieux expliciter dans les README des schémas quel séparateur est préconisé. Cependant, comme évoqué par Johan, cela sera toujours optionnel, car il ne faut pas selon moi pénaliser un producteur de données pour un séparateur non préconisé.

Je veillerai à ce que cette mention soit ajoutée dans les prochains schéma publiés.

Je ferme la discussion, n'hésitez pas à la rouvrir si besoin :).

Bonne journée
Geoffrey