V1.1.2 : délimiteur de colonnes, utilisation de "enum"

[cbenz]

Bonjour @CharlesNepote

Voici une suggestion d'amélioration du schéma :

• spécification du délimiteur de colonnes CSV ","
  • utilise un nouveau fichier goodtables-checks.json pour l'instant séparé, utilisé par Validata, mais a terme sera proposé à l'inclusion dans le table-schema
• utilisation du type "enum" à la place de "pattern"
  • ne change rien au niveau des données

Et quelques détails comme éviter d'utiliser des caractères "échappés" en HTML comme <.

[CharlesNepote]

Le enum est une excellente idée ainsi que les corrections, merci !

Je suis plus dubitatif sur les autres modifications, j'ai besoin de comprendre.

• À propos de "$schema" je comprends la logique mais déjà que j'ai pris un peu liberté par rapport à Table Schema, ça apporte une modification qui nous éloigne plus encore de la spec, car cela sous-entend que le schema pourrait être autre chose que du Table Schema. L'idéal serait de discuter avec les équipes de Table Schema.

• À propos de goodtables-checks.json j'ai deux types d'interrogations :

  • sur le fond je ne vois pas l'intérêt car la RFC donne la virgule comme séparateur donc je ne vois pas pourquoi le redire (cela ne laisse-t-il entendre qu'il pourrait en être autrement) ; il est vrai que je ne l'indique pas dans la spec et je pense qu'il faut que je le précise (mais je ne vois pas pourquoi en rajouter dans la spec)
  • sur la forme :
  • pourquoi avoir choisi json-schema, différent des spec Frictionless ? N'auriez-vous pu choisir https://frictionlessdata.io/specs/csv-dialect/ qui a le bon goût de rester dans l'écosystème Frictionless data ?
  • la présence d'un fichier parallèle complexifie, là ou le shema.json se suffisait à lui-même

[CharlesNepote]

@cbenz est-ce qu'on peut avancer dans la discussion car je voudrais pouvoir faire évoluer le schema ?

[cbenz]

Oui, ça fait plusieurs jours que je dois te répondre :) J'ai quelques points à éclaircir :

À propos de "$schema" je comprends la logique mais déjà que j'ai pris un peu liberté par rapport à Table Schema, ça apporte une modification qui nous éloigne plus encore de la spec, car cela sous-entend que le schema pourrait être autre chose que du Table Schema. L'idéal serait de discuter avec les équipes de Table Schema.

C'est une pratique employée par JSON Schema qui permet d'indiquer depuis le schéma, quel est son propre schéma. C'est très pratique car des éditeurs de code source en tirent partie pour auto-compléter les propriétés du fichier JSON (par exemple VSCode + JSON schema). C'est un peu "meta" je le conçois bien.

À propos de goodtables-checks.json j'ai deux types d'interrogations :

C'est un palliatif que nous avons introduit temporairement pour combler l'impossibilité d'exprimer les custom checks avec leurs paramètres dans le table schema. Il nous fallait pour Validata un moyen de relier les colonnes du schéma à des custom checks, déclarativement. Ensuite, validata-ui charge dynamiquement à la fois les schémas et les fichiers goodtables-checks.json à partir d'un dictionnaire de configuration.

Ce fichier permet également de déclarer ce que nous avons appelé des pre-checks, car ils interviennent avant la validation et sont capables de changer le fichier validé.

Sur le schéma prénoms il y a uniquement le pre-check sur le séparateur de colonnes. Mais sur d'autres, par exemple subventions, on trouve d'autres custom checks comme le numéro SIRET.

A terme ce fichier pourrait être intégré au table schema.

sur le fond je ne vois pas l'intérêt car la RFC donne la virgule comme séparateur donc je ne vois pas pourquoi le redire (cela ne laisse-t-il entendre qu'il pourrait en être autrement) ; il est vrai que je ne l'indique pas dans la spec et je pense qu'il faut que je le précise (mais je ne vois pas pourquoi en rajouter dans la spec)

En pratique on trouve des CSV avec des délimiteur divers. Goodtables ne valide que la structure et les valeurs une fois la table extraite du fichier. Le SCDL définissant l'utilisation du délimiteur de colonne ,, si nous utilisons Goodtables sur un fichier avec des délimiteurs ;, cela passe sans provoquer d'erreur. Au niveau Validata nous avons donc ajouté un pre-check, avant Goodtables, pour s'assurer de l'utilisation de la ,. Pour activer ce pre-check, il faut ce fichier de configuration.

pourquoi avoir choisi json-schema, différent des spec Frictionless ? N'auriez-vous pu choisir https://frictionlessdata.io/specs/csv-dialect/ qui a le bon goût de rester dans l'écosystème Frictionless data ?

Nous avons choisi table schema, pas JSON schema. Cependant les schemas table-schema sont eux-mêmes définis par un JSON schema.

la présence d'un fichier parallèle complexifie, là ou le shema.json se suffisait à lui-même

J'espère que mes réponses ont été suffisamment claires pour te montrer que justement schema.json n'était pas suffisant pour définir des pre-checks, et des custom-checks.