Correctifs en vue de la publication du schéma

[johanricher]

Bonjour,

Bravo pour ce travail. J'imagine que la prochaine étape est la publication grand public de ce schéma ? Par exemple dans les catalogues de schéma Socle commun des données locales et schema.data.gouv.fr.

Les pré-requis pour publier sur schema.data.gouv.fr (https://schema.data.gouv.fr/documentation/validation-schemas) sont très similaires à ceux du SCDL (https://scdl.opendatafrance.net/docs/CONTRIBUTING.html), tout simplement car le premier a découlé du travail d'OpenDataFrance qui a été réalisé à l'occasion du projet Validata.

Les remarques suivantes sont donc générales et vous recevrez un retour similaire de la part d'Etalab si vous leur proposez le schéma :

• il manque un tag git correspondant à la version du schéma que vous publiez (1.0.0)
• les URL dans le schéma doivent pointer vers la source qui est ce dépôt
  • homepage doit pointer vers ce dépôt (https://github.com/Alkante35/schema-dae/)
  • path doit pointer vers la version du schéma (https://github.com/Alkante35/schema-dae/raw/v1.0.0/schema.json quand le tag sera appliqué)
  • idem pour les fichiers exemple
• il semblerait que les fichiers d'exemple exemple_invalide_complet.csv et exemple_invalide_structure.csv ne soient pas valides et ne peuvent pas être chargés par la librairie Tablib utilisée par Validata (vous devez consulter les logs pour voir les erreurs).

La meilleure méthode pour tester la conformité d'un schéma reste de tester avec Validata en local pour avoir accès aux logs (docker-compose logs -f), ce qui est rendu facile grâce à Docker (https://git.opendatafrance.net/validata/validata-docker). Vous pouvez également tester le schéma en ligne avec la fonction "à la carte" de Validata (go.validata.fr), cela permet de s'assurer que tout fonctionne bien, comme le fait que la validation des fichiers d'exemple aboutisse, mais vous n'aurez pas accès aux logs. Une fois que vous êtes sûr que le schéma est correct et que les fichiers d'exemple passent la validation, vous pouvez faire une release.

Mon avis personnel :

• il serait préférable à mon avis de ne pas publier en v1.0.0 avant d'avoir pu recueillir davantage de remarques du grand public et d'itérer rapidement avec des correctifs, sans avoir à ce soucier de la rétro-compatibilité du schéma. C'est le but de la phase initiale de développement (0.x.y). Le grand public doit pouvoir s'attendre à ce qu'une v1 soit finalisée et stable. Plus d'informations sur ces notions : https://semver.org/lang/fr/#faq
• il serait préférable de publier le schéma sur un dépôt gouverné par l'autorité en charge du schéma et pas par un prestataire. En effet, la gestion par le prestataire est limitée dans le temps et si rien n'est fait il est inévitable que le dépôt doive tôt ou tard bouger, ce qui entrainera une indisponibilité pour les personnes et infrastructures qui dépendent du schéma. Là aussi, le grand public doit pouvoir s'attendre à ce que lieu de publication du schéma est stable dans le temps.

[Fonaine]

Bonjour, et merci pour votre retour complet. Nous sommes en train de faire le nécessaire pour faire héberger le projet par une autorité publique. S'agissant des URL et du tag 1.0.0, ce sera corrigé lors du passage au dépôt public. S'agissant des fichiers non valides, c'était une volonté de notre part, pour donner des exemples non valides, en structure, comme en donnée, afin d'illustrer les vérifications faites par Validata. Mais, si je comprends bien votre remarque, ce n'est pas une bonne pratique dans le référencement du schéma ? Vous confirmez ? Si c'est le cas, nous les supprimerons. merci d'avance.

[johanricher]

Merci pour votre réponse.

Concernant les fichiers "non valides" je me suis mal exprimé ; je ne voulais pas dire qu'ils n'étaient pas conformes au schéma DAE. C'est en effet une bonne pratique, que vous avez suivie, de proposer des fichiers comportant des erreurs que pointera le validateur, à fin d'exemple à ne pas suivre pas les utilisateurs.

Je voulais signifier que ces fichiers ne semblent pas conformes au format CSV. En l'occurence ils ne peuvent même pas être chargés par Validata qui renvoie respectivement ces erreurs :

• Fichier exemple_invalide_structure.csv : "IndexError: list index out of range"
• Fichier exemple_invalide_complet.csv : "tablib.core.InvalidDimensions"

---

Vous pouvez constater ce problème si vous essayez de valider ces fichiers dans Validata, vous recevez cette erreur dans l'interface :

Et dans les logs :

[johanricher]

Pour information, ces erreurs dans les fichiers CSV sont relevés par Github :

• https://github.com/Alkante35/schema-dae/blob/master/exemple_invalide_structure.csv

  La 3ème ligne devrait avoir 44 colonnes au lieu de 43

• https://github.com/Alkante35/schema-dae/blob/master/exemple_invalide_complet.csv

  La 2ème ligne devrait avoir 43 colonnes au lieu de 44

Le service de validation en ligne CSVLint vous informe également :

• https://csvlint.io/validation/5e341879b01806000400004e
• https://csvlint.io/validation/5e341843b01806000400004d

[Fonaine]

Les 2 fichiers incorrects ont été mis à jour.