:::info
- Ce pad : https://hackmd.io/@multi/validata-table
- [**Dépôt Gitlab**](https://gitlab.com/validata-table/validata-table)
- :construction: [Priorisation des tâches du backlog](https://hackmd.io/DuhRBw48SgeSfmPmZ8Or8g)
:::

## 2024-03-13 Proposition de pattern pour les formats personnalisés

[Lien vers le pad dédié](https://hackmd.io/KEH5BY7TQ9ykg6NdfRKdcQ)

## 2024-03-12 Echanges avec Données et territoires

Personnes présentes : Ronan Amicel, Vincent Lara, Amélie, Pierre, Johan

[Idées d'améliorations de la spec Table Schema, en vue de la v2](https://hackmd.io/yn9-tVPcQo-aT_ZtBoj3bg)

Poursuite des échanges : proposition de travailler conjointement aveDonées et territoires sur la proposition de pattern pour répondre aux [besoins évoqués en premier lieu par Johan Boniface](https://github.com/frictionlessdata/specs/issues/817) -> proposition de propriété de champs `type_annotation` qui pourrait s'appliquer et resterait ouvert, et chaque outils de validation aurait sa propre manière de valider ces types_annotations

## 2024-03-11

Proposition commerciale

Situation actuelle : dev 5 jours / semaine + PO 1 j / s, TJ 700 € HT

3 lignes de négo
* Embarquement Oumeima : organisation normale équipe (2 dev + 1 PO), montée en compétence sur Validata non facturée
* Augmentation volume jours dev : conforme à la vélocité souhaitée
* Augmentation TJ Pierre et Johan : normal, reste inférieur à notre TJ habituel, inflation

Scénario 1 (notre scénario)

* PO (Johan) : 1 jour / semaine, TJ 800 € HT
* Lead tech (Pierre) : 3 j / s, TJ 800 € HT
* Dev (Oumeima) : 3 j / s, TJ 700 € HT

Embarquement d'Oumeima non facturé (6 jours)

Scénario 2 (leur scénario)

* PO (Johan) : 1 jour / semaine, TJ 800 € HT
* Lead tech (Pierre) : 3 j / s, TJ 800 € HT

## 2024-03-08 Proposition d'intégrer le pattern metadata à la spec v2

Créer un ticket sur [`specs`](https://github.com/frictionlessdata/specs/) pour proposer que la spec Table Schema en V2 intègre [le pattern Metadata Properties](https://specs.frictionlessdata.io/patterns/#table-schema-metadata-properties) en argumentant que :
* déjà en partie implémenté dans `frictionless-py` et non spécifié ni documenté
* adoption relativement large depuis 2019 (x schémas français sur schema.data.gouv.fr)

[Proposition résultante de pattern](https://hackmd.io/JsnK1v7JT0-KHZxGHkN5ww?view)

## 2023-10-25

[Frictionless Community Call](https://docs.google.com/document/d/1chRTxCTo-_HIfCdGv5ApmR2PObk_ISf1Vt-vRTBbMFM/edit#heading=h.50msdywrngj0): **Frictionless Specs Review**

> After 5 years from the release of Data Package v1, it’s now time for an update. 🚀

[Specs v2](https://github.com/frictionlessdata/specs/milestone/6)

> This v2 list of issues is not finalized, it's a starting point

Inclu : https://github.com/frictionlessdata/specs/issues/817

## 2023-09-27

[Kanban](https://github.com/orgs/etalab/projects/6/views/62)

* Process de release Validata
* à chaque bugfix ou ajout de nouvelle feature ?
* de façon régulière, batch de MR ?

Issues sur https://github.com/etalab/validata.etalab.studio/issues ?

### Notes

* [Migration gitlab](https://hackmd.io/oc-RAIWCT1u_7elGII9WXQ)
* SCDL ?
* ODF
* Fabrique des standards
* CNIG
* Publication sur schema.data.gouv
* [État des lieux de l’archi de Validata Table](https://hackmd.io/qKbrxYQ5RU6NmxFPUivUNw)

Mise en prod et on planche sur le monorepo

## 2023-09-13 Tri des tickets Qualité

Réunion sprint / rétro data.gouv.fr toutes les 2 semaines le mercredi de 15h à 17h, en présentiel (Ségur) et sur Discord.

Sensibilité à la casse dans l'en-tête, ajout d'un switch dans l'UI. Décision prise de mettre par défaut "on"

Besoin remonté par Cyril Morin (via Pierlou)

## 2023-09-06 Réunion de démarrage [Chantier Qualité](https://gitlab.com/multi-coop/crm/-/issues/91)
Présents :
- multi : Pierre et Amélie
- DINUM :
- Geoffrey Aldebert (Opérateur des produits interministériels)
- Pierre-Lou Ramade (data eng)
- Antonin garonne (PO data.gouv)
- Estelle (dev)

### Organisation :
[Board de la DINUM](https://github.com/orgs/etalab/projects/6/views/62)

Sprint de 2 semaines

Réunion de préalable pour préparer la planif (priorisation des issues pour le sprint suivant) : toutes les deux semaines : 30 minutes les mercredi matin à 11h30 - prochaine réu le mercredi 13/09

Réunions de revue de sprint toutes les 2 semaines - mercredi aprem intégrée à la réunion d'équipe de la DINUM décomposée en 3 temps : démo, planif, rétro - en présentiel ou sur discord - prochaine = mercredi 13/09

### Thèmes de travaux abordés par la DINUM

Gros chantiers :
- Validata Table (dans un premier temps) & Json
- Bugs
- Chantier de fond sur archi Validata
- Partie performance de Validata (réflexion sur laquelle Pierre avait travaillé sur la validation asynchrone de ValidataJson à mener aussi sur Validata Table)
- Réflexion sur la validation de datapackages : quel point de vue UX ?

- Données pivots (Travaux menés par data.gouv)

- Actions sur des schémas partiucliers en lien avec la fabrique des standards (au fil del'eau)

- Interactions quant à la production de données dans le cadre de schéma de données (publier.etalab.studio)

### Questions particulières sur déploiement
- Hébergement -- gardé par la DINUM
- Déploiement -- on peut s'en charger (Amélie a un accès à la machine)

### TODO:
- [ ] créer compte discord (Amélie, Pierre, Johan)
- [X] rajout issues validata table sur le board de la DINUM (Amélie) sur le board de la DINUM (Amélie)
- [x] rajout issues frictionless sur le board de la DINUM (Amélie)

## 2023-09 Presta DINUM

À partir de septembre on démarre une [prestation pour la DINUM](https://gitlab.com/multi-coop/crm/-/issues/91) pour travailler sur Validata Table, [Validata JSON](https://hackmd.io/@multi/validata-json) et des tâches liées.

Sur le périmètre Validata Table (et l'écosystème logiciel basé sur Table Schema et Frictionless Data) :

* Maintenance (bugs et petites fonctionnalités d'usage)
* Nouvelle spécification ("Extension") française Frictionless Framework (s'inscrit dans la suite des ateliers "Format / données pivot" cf. les CR ci-dessous et avec une gouvernance DINUM / ANCT
* Comprendre plus en détails en discutant avec Geoffrey :
* Étude sur la possibilité d'éditer des jeux de données sur data.gouv.fr
* Nouvelle infra data.gouv.fr (données intégralement mises en base et associées à un schéma) et usages à développer par-dessus
* Contributions diverses à Frictionless framework (cf issues ci-dessous)
* Qui a la responsabilité du déploiement ?

Concernant Validata Table :

- Maintenance évolutive. Temporalité ?

Mode de fonctionnement proposé :

- Suivi tâche par tâche dans un tableau dédié partagé (avec estimation et état d'avancement)
- Validation explicite des tâches avant engagement

### Détail Maintenance évolutive Validata Table

La roadmap (tâches à faire) sera discutée avec la DINUM et validée par eux. Afin qu'on puisse pousser ce qui nous paraît le plus pertinent, il faudrait d'ici septembre :
* Pour Validata Table : préparer la priorisation du [backlog](https://git.opendatafrance.net/groups/validata/-/boards) : [proposition de priorisation](https://hackmd.io/DuhRBw48SgeSfmPmZ8Or8g?both)

### Détail contributions à Frictionless Framework

* Pour Frictionless Framework : identifier des tâches
* https://github.com/frictionlessdata/framework/issues/1521
* https://github.com/frictionlessdata/framework/issues/1442
* https://github.com/frictionlessdata/framework/issues/1434
* https://github.com/frictionlessdata/specs/issues/736
* https://github.com/frictionlessdata/framework/issues/1339
* https://github.com/gristlabs/grist-core/issues/423
* Divers : lister ci-dessous autres points à aborder avec DINUM pour valider si c'est dans le scope de la presta ou pas (contours sont pour l'instant assez flous donc on peut en profiter)

## 2023-01-27 Point Validata-Table ODF

Contexte : faire suite à la réunion avec ODF du 13/01/2023 pour définir les tâches à réaliser en priorité au regard du budget restant d'ODF
Présents : Jean-Marie Bourgogne (ODF), Quentin, Amélie

Pour Jean-Marie, la priorité est de travailler sur les tâches déjà en cours de réalisation pour les terminer, à savoir :
- Terminer le travail sur le numéro RNA dnas le schéma Subventions associé au rajout d'un nouveau custom check one-of-required
- Dans la continuité du travail réalisé sur le filtre des custom checks, refactorer le code pour rajouter une classe parent sur les custom check

Les autres tâches identifiées dans le [tableau de suivi ](https://docs.google.com/spreadsheets/d/13TKOfoahOi5igWiErSQ3pxu7gaCUrVKlvZrs12VO0yo/edit?skip_itp2_check=true#gid=0) ont été mise en stand by par ODF pour le moment (statut "bloqué" dans le tableau).

Jean-Marie Bourgogne souhaite refaire un point d'ici 2 semaines pour voir l'état d'avancement de ces travaux particuliers en vue d'une prochaine facture pour englober les travaux terminés depuis la dernière facture du 13/01/2023.

## 2023-07-25

Veille

[Compte-rendu de la réunion #16 du GT QuaDoGéo du 04 mai 2023](https://nuage.liiib.re/index.php/f/3698298) (groupe de travail du CNIG sur la qualité des données géographiques), en particulier les interventions de Mathieu Rajerison (CEREMA) :
* ATELIER TableSchema
* [Quadorender](https://gitlab.cerema.fr/mathieu.rajerison/quadogeo/-/blob/master/QUADORENDER.md)

## 2023-01-26 Compte-rendu données budget

Présents :
- Adrien Pavie
- JMB
- Quentin
- Pierre

Décision prise avec Quentin avant la réunion que c'est Pierre qui suivrait ce sujet.

Réunion pour essayer d'y voir un peu plus clair sur les problèmes rencontrés dans [ce thread](https://teamopendata.org/t/scdl-donnees-essentielles-de-budget/3797)

A priori, personne ne comprend trop pourquoi les données ne sont pas ouvertes au niveau national, sachant qu'elles sont déjà consolidés via la base Totem.

Deux leviers sont évoqués, dont on peut se saisir (bénévolement) chez multi :
- Demande CADA
- En discuter avec Geoffrey

En attendant, les constats suivants ont été faits :
- C'est totem2csv qui ne fonctionne pas bien
- Ce n'est pas surprenant car ça a été développé lors d'un hackaton et que ce n'est plus maintenu
- ODF est prêt à financer la remise en route de cet outil par multi (pas clair sur quel budget), mais pas de s'engager plus dans l'outillage pour les données budget. On peut demander un échange avec Pascal Romain pour nous aider dans cette démarche.
- Le convertisseur n'aurait pas trop vocation à être dans DataClic, qui propose plutôt de l'extraction de données que des services de conversion. Mais à défaut de mieux et de budget, on reste sur ce statut quo.

qui suivrait ce sujet.

Réunion pour essayer d'y voir un peu plus clair sur les problèmes rencontrés dans [ce thread](https://teamopendata.org/t/scdl-donnees-essentielles-de-budget/3797)

A priori, personne ne comprend trop pourquoi les données ne sont pas ouvertes au niveau national, sachant qu'elles sont déjà consolidés via la base Totem.

Deux leviers sont évoqués, dont on peut se saisir (bénévolement) chez multi :
- Demande CADA
- En discuter avec Geoffrey

En attendant, les constats suivants ont été faits :
- C'est totem2csv qui ne fonctionne pas bien
- Ce n'est pas surprenant car ça a été développé lors d'un hackaton et que ce n'est plus maintenu
- ODF est prêt à financer la remise en route de cet outil par multi (pas clair sur quel budget), mais pas de s'engager plus dans l'outillage pour les données budget. On peut demander un échange avec Pascal Romain pour nous aider dans cette démarche.
- Le convertisseur n'aurait pas trop vocation à être dans DataClic, qui propose plutôt de l'extraction de données que des services de conversion. Mais à défaut de mieux et de budget, on reste sur ce statut quo.

## 2023-01-11 Format / données pivot

Suite de la réunion du 16/12/2022. Personnes présentes (remote) : Geoffrey, Renan, Yohan Boniface, Amélie, Pierre, Johan.

Prochaine réunion dans ~2 semaines

TODO multi : Vérifier la possibilité avec une extension à framework qu'on puisse valider des schémas avec des nouvelles propriétés `format-fr`.

Périmètre du test ; siret (stdnum.fr.siret), existe ou pas (API Sirene)

Voir aussi du côté de [ce qui a été fait sur insitu](https://datahub.incubateur.tech/infrastructure/insitu/-/blob/main/insitu/datasets/frictionless_plugins/commune.py)

Voir avec JMB la question du financement de la partie des travaux menée par multi.

## 2022-12-16 Format / données pivot

[Suite de la précédente réunion](#2022-11-30-Format--donn%C3%A9es-pivot) du GT commun Etalab / D&T / multi (Validata). Personnes présentes (remote) : Geoffrey Aldebert, Pierlou Ramade, Yohan Boniface, Johan.

* Johan a présenté [le lexique](https://pad.incubateur.net/HtSZYI0STsCcZEvQkTeVOQ) et on a bien avancé dessus
* Yohan a présenté les premières [users stories](https://pad.incubateur.net/j7u1CQuPSbC1Wrob6DeQmA?both#User-stories)
* [Benchmark](https://pad.incubateur.net/j7u1CQuPSbC1Wrob6DeQmA?both#Benchmark)
* on a discuté de l'analyse de Pierre qui semble une piste très intéressante
* on a discuté de la possibilité de plugin / extension à frictionless (qui n'existait pas au début de validata) et de ce que ça changerait pour validata-core, pour mieux servir aux besoins de D&T
* en fonction de tout ça, et pour une première prise de contact auprès de la communauté frictionless pour vérifie que ce qu'on veut faire n'existe pas déjà, on a décidé du [texte que Yohan a ensuite posté sur un ticket](https://github.com/frictionlessdata/specs/issues/817)

On doit prendre tout ça en compte pour réfléchir à l'avenir de Validata, en se posant la question de qui est aujourd'hui le périmètre essentiel des différentes librairies (UI, API, Core). `validata-core` a peut-être vocation à devenir "frictionless-fr" pour recentrer son périmètre et penser à d'autres usages que ceux actuels (Validata API et UI). Ce qui est nouveau c'est que D&T serait utilisateur d'une telle librairie / outil CLI, sans l'API / UI. Etalab et le PAN ont besoin de l'API (dont ils continueront à administrer la prod).

Prochaine réunion le mercredi 11 janvier (remote possible). La présence de @qloridant @pierrecamilleri @arondot serait utile je pense.

## 2022-12-16 Point équipe

Point sur le projet avec Amélie, Quentin et Johan

### Budget

Manque de cohérence entre Dataclic et le schéma Budget. La page "Budget" de Dataclic (https://dataclic.fr/budget) devrait très simplement permettre de produire un seul fichier CSV, et ce fichier devrait être 100 % conforme au schéma "Budget" (http://schema.data.gouv.fr/scdl/budget/). Du point de vue utilisateur, c'est ce qui est attendu.

Si ODF décide que le schéma "budget" ne change pas, alors c'est à Dataclic d'évoluer, de façon à produire un fichier budget conforme au schéma.

[totem2csv](https://gitlab.com/datafin/totem/-/tree/master/totem2csv), qui est utilisé par Dataclic, doit par ailleurs peut-être être amélioré pour d'autres raisons ? Est-ce que le [M57 de totem](http://odm-budgetaire.org/) est pris en compte par totem2csv ?

- [ ] Valider avec JMB que le schéma budget n'évolue pas (si JMB n'est pas sûr, proposer que multi anime un GT avec les "experts" qu'on connait pour investiguer et faire évoluer le schéma)
- [ ] Proposer de reprendre Dataclic & Totem2csv sous le giron d'ODF (gouvernance compliquée avec des éléctrons libres)
Interlocuteur clair pour les usagers
- [ ] Proposer à JMB de faire une réponse [sur Team Open data](https://teamopendata.org/t/3797/) (lui-même ou nous au nom d'ODF) qui met en cohérence Dataclic avec le schéma budget, en proposant une nouvelle version, etc. Proposer la contribution de Guillaume

### Validata-Table

Passage en revue du [backlog](https://git.opendatafrance.net/groups/validata/) et du [tableau de suivi](https://docs.google.com/spreadsheets/d/13TKOfoahOi5igWiErSQ3pxu7gaCUrVKlvZrs12VO0yo/edit).

Ajout de 2 labels "A discuter" et "Commandé" pour correspondre au tableau de suivi et notamment pour identifier plus facilement les tickets qui n'y sont pas encore

Batch de tâches / tickets "A discuter" qu'il faut faire valider par ODF, et d'autres "Terminé" qu'il faut facturer (à priori en janvier).

## 2022-12-14 Dataclic - Validata avec le Grand Est
Présents : Guillame, Mickael Vadin, Adrien Pavie

Données budget.
Le Grand Est utilise la conversion sur dataclic puis la validation sur Validata.

Intervention de Guillaume :

Ils ont des budgets qui ne sont pas validés : erreur de conversion ? erreur de validation ?

* Questions sur la publication :
Une 30aine de fichiers a publier chaque année pour les acteurs.
Retex d'autres collectivités ?

* Certains csv générés par Dataclic sont vides. Quoi en faire ?

* Problème de conversion du budget de la région : le budget est décomposé par fonctions

Dataclic est le pendant de l'outil GeoDatamin
Transformer des bases nationales en extractant des fichiers par collectivité.

Notes :
* Changement au 1er janvier 2023 : https://www.collectivites-locales.gouv.fr/finances-locales/le-referentiel-budgetaire-et-comptable-m57
* https://teamopendata.org/t/scdl-donnees-essentielles-de-budget/3797/4
* https://github.com/dtc-innovation/anonymisation-document-budgetaire
* https://gitlab.com/datafin/totem
* Les erreurs sur la conversion interviennet sur les fichiers 2020
* La dministration a tous les fichiers XML de budget. Pq ne pas centraliser ?

## 2022-12-07 Création de schémas

Réflexion sur la [création de schémas](https://hackmd.io/SEQQtfs5RPyuNkq5SWzpfQ), pouvant hypothétiquement mener à un outil "Table Schema Creator".

## 2022-11-30 Format / données pivot

Atelier données pivot - Etalab / ANCT / multi (Validata)

Personnes présentes : Geoffrey Aldebert, Estelle Maudet, Pierlou Ramade, Yohan BONIFACE, Raphaël Pierquin, Amélie Rondot, Pierre Camilleri, Thomas Brosset, Johan

[Pad](https://pad.incubateur.net/j7u1CQuPSbC1Wrob6DeQmA)

## 2022-09-19 Documentation architecture

Mise à jour du [diagramme de 2019](https://hackmd.io/A89id30hQVGuSdrMbzVHpQ?both#Architecture-Validata)

Les cards sont cliquables.

graph TD

subgraph Validata Table
    UI[validata-ui]
    API[validata-api]
    core[validata-core]
    UI-config(config.yaml)
end

    schema[Schémas]
    catalog[Catalogue de schémas]
    ODS-py[opendataschema-python]
    TS[Spécification<br>Table Schema]
    schema-catalog[Spécification<br>schema-catalog]
    
    UI -- utilise --> core
    API -- utilise --> core
    UI === UI-config
    UI-config -- référence --> catalog
    catalog -- référence --> schema
    UI -- utilise --> ODS-py
    ODS-py -- pour intéragir avec --> catalog
    catalog -- défini par --> schema-catalog

    schema -- défini par --> TS
    core -- utilise --> frictionless-py

subgraph FD[Frictionless Data]
    frictionless-py -- utilise --> TS
end
    
    click UI "https://git.opendatafrance.net/validata/validata-ui"
    click API "https://git.opendatafrance.net/validata/validata-api/"
    click core "https://git.opendatafrance.net/validata/validata-core/"
    click UI-config "https://git.opendatafrance.net/validata/validata-ui/-/blob/v0.6.12/config.example.yaml"
    click ODS-py "https://framagit.org/opendataschema/opendataschema-python"
    click TS2M "https://framagit.org/opendataschema/table-schema-to-markdown"
    click frictionless-py "https://github.com/frictionlessdata/frictionless-py/"
    click TS "https://frictionlessdata.io/specs/table-schema/"
    click catalog "https://git.opendatafrance.net/scdl/catalog/blob/master/catalog.json"
    click schema-catalog "https://framagit.org/opendataschema/catalog/blob/master/schema-catalog.json"

## 2021-12-02 Next steps

- L'étude concernant le contrôle de schéma Json dans la perspective d'engager le projet Validata NG, à travers la mise en place d'un démonstrateur sur le schéma des pistes cyclables. Nous sommes en stade d'identification des approches et des technologies possibles pour ce projet.
- La convergence des instances validata et la refonte de sa home page
- La création d'une IHM qui permette d'automatiser la génération du fichier de description de schémas

### TODO

- Facturer lot 1
- Prochaine réunion : présenter état des réflexions sur [validateur JSON](https://hackmd.io/yIM44TsCSSegSZPIdQxSMQ?both#2) et solution technique pour catalogue de schémas (indexer métadonnées), dont dépend la refonte de la home (et une fonctionnalité de filtrage / recherche avancée sur schemadatagouv à plus long terme)
- Table Schema Creator : devis
- relancer https://git.opendatafrance.net/validata/validata-core/-/issues/18

## 2021-09-15 - Analyse des tickets ouvert pour OpenDataFactory

Parmi [ces tickets](https://git.opendatafrance.net/groups/validata/-/issues?scope=all&state=opened&label_name[]=OpenDataFactory), lesquels sont encore pertinents et quel est l'effort de développement correspondant ?

### Scope lot 1 à trancher par ODF

#### [Custom check: opening hours](https://git.opendatafrance.net/validata/validata-core/-/issues/17)

1) Il faudrait aller plus loin dans la spécification de ce ticket notamment dans les langues à supporter (hors français) et écrire des exemples valides.
2) L'étape suivante est de vérifier qu'au moins une des librairies Python actuelles supporte bien les exemples choisis.

Temps estimé : 1,5j/h pour les deux premières étapes. Il sera alors possible d'évaluer le temps de développement de ce custom check

Nogo si la librarie ne répond pas au besoin. Implémentation environ 1 jour. Total : 3 jours max

#### [Custom check : phone numbers](https://git.opendatafrance.net/validata/validata-core/-/issues/16)

- Même remarque que l'issue précédente

Total : 3 jours max

#### [Améliorer le custom check nomenclature Actes](https://git.opendatafrance.net/validata/validata-core/-/issues/9)

La [spécification initiale](https://git.opendatafrance.net/validata/validata-core/-/blob/master/validata_core/custom_checks/nomenclature_actes_value.py) de ce custom check indiquait que le libellé de nomenclatures devait être directement suivi par une oblique (/).

Dans le fichier testé, il y a une espace entre le libellé et l'oblique, ce qui provoque une erreur.

Plusieurs possibilités :
- modifier le custom check pour afficher un message d'erreur plus explicite dans ce cas là, ex : "Attention, le libellé de nomenclatures doit être suivi immédiatement d'une oblique !"
- modifier le custom check pour autoriser l'ajout d'une espace entre le libellé et l'oblique (est-ce que l'on doit accepter les deux formes : avec ou sans espace ?)

Dans tous les cas, c'est une décision à prendre, la modification est rapide à effectuer.

2e cas avec tous les cas de figure de séparation "/" avec ou sans espace

Estimation : 0,5 max

#### [Make errors related to custom checks more explicit](https://git.opendatafrance.net/validata/validata-ui/-/issues/103)

- Les erreurs émises par les `custom checks` apparaissent dans le rapport de validation mais pas encore de manière assez structurées pour être exploitable dans l'UI de Validata

TODO:
- mieux structurer ce type d'erreur (`validata-core`)
- présenter les erreurs de manière explicites (`validata-ui`)

Temps estimé : ~2j/h

#### [Xlsx validation](https://git.opendatafrance.net/validata/validata-ui/-/issues/99)

Cela ne nous concerne pas directement.

On peut toujours le réévaluer après la mise à jour à la dernière version de `frictionless-py` et ouvrir une issue si le problème persiste.

Durée estimée : 0.5 à 1j/h pour ouvrir une issue upstream

#### [Problème au niveau du rapport Validata sur les dates](https://git.opendatafrance.net/validata/validata-core/-/issues/20)

- À implémenter : 1j/h

### Travail exploratoire nécessaire (à discuter avec Thierry)

#### [Internal Server Error à la soumission du formulaire de validation](https://git.opendatafrance.net/validata/validata-ui/-/issues/104)

#### [Make errors related to duplicate columns more explicit](https://git.opendatafrance.net/validata/validata-ui/-/issues/105)

#### [Validation of values in arrayItem](https://git.opendatafrance.net/validata/validata-core/-/issues/18)

- Pas d'avis sur la question. Cette dernière dépend fortement du bon vouloir de `frictionless`

A designer, le cas échéant issue voire PR à ouvrir upstream mais dans le cadre d'un lot ultérieur.

#### [Message d'erreur explicite si le fichier tabulaire est trop lourd à charger](https://git.opendatafrance.net/validata/validata-ui/-/issues/68)

#### [Problems related to schema/catalog loading](https://git.opendatafrance.net/validata/validata-ui/-/issues/62)

Le cache est en place depuis un moment maintenant. Est-ce que le problème de blacklist est toujours constaté ?

2 problèmes à résoudre
- Le temps de chargement de la page d'accueil de l'instance ODF (plus long que celui de [l'instance etalab](https://validata.etalab.studio/))
- Ne pas taper dans l'API de Github à chaque chargement du catalogue par la home Validata

TODO Pierre : étudier 1) le cache actuel 2) l'implémentation etalab

#### [Skip blank lines before header](https://git.opendatafrance.net/validata/validata-core/-/issues/1)

### Ticket à fermer / Won't do

#### [Connecteur sur OpenRefine](https://git.opendatafrance.net/validata/validata-ui/-/issues/108)

#### [Prise en compte des custom check](https://git.opendatafrance.net/validata/validata-ui/-/issues/107)

#### [Audit traitement colonne surnuméraire](https://git.opendatafrance.net/validata/validata-ui/-/issues/106)

1j/h pour écrire un schéma et un CSV minimal qui met en lumière ce qu'affiche (ou n'affiche pas) Validata dans le cas de colonnes présentes dans le fichier CSV mais pas dans le schéma.

Travail de vérification d'un point de vue utilisateur à faire par ODF, si besoin ça serait un ticket à traiter dans un lot ultérieur

#### [Améliorer le custom check de cohérence entre colonnes](https://git.opendatafrance.net/validata/validata-core/-/issues/10)

#### [Fix validation when field name contains an accent](https://git.opendatafrance.net/validata/validata-core/-/issues/6)

## 2020-12-02

### Préparation point Etalab
- issue 72, 73 : se mettre d'accord sur le résultat de validation souhaité
- issue 74 : pb de style
- sso datagouv : qui contacter pour avoir des informations ?
- csv-gg : est-ce qu'il existe déjà des widgets personnalisés ?

## 2020-11-27

Suite à la discussion avec Christophe hier à propos de la migration vers `frictionless-py`:
- ne pas travailler en mode tunnel, voir les tickets corollaires en //
- améliorations possibles :
- traitement sur les headers : travailler en mode stream en faisant du réordonnancement de colonnes en itératif (avant le traitement de chaque ligne)
- pour le rapport, créer un format Validata pas forcément basé sur JSON (en utilisant un modèle pydantic ?)
- à régler :
- custom loader (ou custom source) pour le traitement des fichiers uploadés (disponibles sous forme de bytearray)
- filtrage des erreurs entre :
- général
- structure (header)
- body
- garder un œil sur https://github.com/frictionlessdata/frictionless-py/issues/551

## 2020-11-23 Validata pour Etalab

Presta pour Etalab : Validata / Table Schema / CSV-GG / Datagouv / Schema Catalogue

[Pad et Roadmap](https://pad.incubateur.net/ZAFnwKLpSwi_zj3_4eJAFA)

[Migration vers frictionless-py](https://git.opendatafrance.net/validata/validata-core/-/issues/13)
- [Tests exploratoires de Pierre](https://git.opendatafrance.net/validata/frictionless-py-tests) en vue de la

Différents points de Validata à arbitrer entre contribuer upstream et porter à la nouvelle lib.

| Feature | Where |
| -------- | -------- |
| i18n des messages d'erreur upstream | upstream |
| custom checks non orientés "row stream", par ex sur les colonnes | custom check on cell + unique constraint in schema |
| les colonnes surnuméraires ne provoquent pas d'erreur | validata as a proxy |
| l'ordre des colonnes est ignoré | validata as a proxy |
| erreurs de type MIME (e.g. soumettre un JPEG) | upstream (already done) |
| détecter l'encodage des CSV (bug chardet) | upstream (chardet) or Validata (+ pass encoding) |
| ignore blank lines | Validata as a proxy |

Questions frictionless :

- 1 plugin Validata pour tous nos ajouts ? ou 1 par custom check ?
- y a-t-il toujours des counts dans le *report*, ou autres changements ?
- y a-t-il une classe Python pour manipuler le report ?

Changements API Python :

- API des custom checks
- registry => plugin

### Archi Validata

# data flow
{CSV, XLSX, ...} => preprocess => validate => postprocess => display errors

preprocess :

- reorder columns as schema
- remove blank lines

postprocess :

- reorder columns as original table
- adapt errors: remove "wrong column order" errors, update counts

Questions archi :

- on garde Validata comme une appli Flask
- passe-t-on à un modèle asynchrone de validation ? pour l'API, l'UI ou les deux ?

# dependencies
UI => CORE
API => CORE
CORE => (frictionless)

### Issues

- https://github.com/frictionlessdata/frictionless-py/issues/544
- https://github.com/frictionlessdata/tabulator-py/issues/265#issuecomment-732094233

## 2020-10-07 BAL

https://github.com/etalab/schema.data.gouv.fr/issues/122#issuecomment-704878861

## 2020-04-02 Mise à jour de Validata

- La dernière livraison de Validata date d'il y a 3 mois
- Les projets sous-jacents évoluent
- Certains utilisateurs (comme Antoine Augusti) ont contribué au code et souhaiteraient avoir une nouvelle release
- ce matin pdi a:
- mis à jour les dépendances de validata-core
- releasé une nouvelle version du module
- idem pour validata-api et validata-ui
- déployé sur le serveur go.validata.fr
- problème : sur la page d'accueil de go.validata.fr, de nombreux schémas étaient affichés comme indisponibles
- je suis revenu sur les versions précédentes (dans docker-compose.yml) et le service est à nouveau disponible

Les problèmes détectés :
- depuis la version 1.12.15 de tableschema, la validation du schéma est plus stricte (https://github.com/frictionlessdata/tableschema-py/commit/c9ed4d1f95db44dfd9d2072c631c82e23cfa2853). Cette version de tableschema est intégrée dans les dernières versions de goodtables-py. Or un certain nombre de schémas pointés par Validata comportent des erreurs (d'où leur affichage en `indisponible`)
- je peux "relâcher" la validation au niveau de l'UI pour éviter le problème dans l'UI mais ensuite, je n'ai pas les moyens de désactiver la validation au sein du code de goodtables-py.

- En testant localement, je m'aperçois que certains de nos custom validators plantent car ils reçoivent des valeurs qui ne sont pas des chaînes de caractères (comme si le force_strings=True ne jouaient plus son rôle). Je blinde ces validateurs au fur et à mesure des erreurs rencontrées.

- Que faire à partir de là ?
- terminer l'adaptation du code par rapport aux dépendances et mettre à jour go.validata.fr, charge aux mainteneurs de schémas de corriger les problèmes
- creuser pour voir si on peut passer sous silence les erreurs de validation de schéma pour maintenir le service en fonction quitte a afficher un avertissement sur la page de rapport de validation : "Attention, des erreurs ont été détectées dans le schéma .... Le rapport peut être faussé."

## 2019-10-31 POC Validata JSON

L'idée est de faire comme Validata pour les CSV avec Table Schema, mais pour les JSON avec JSON Schema.

Existing tools:
- https://github.com/json-editor/json-editor
- https://jsoneditoronline.org/
- https://www.jsonschemavalidator.net/

Plan s'il faut coder qqch:
- reprendre les concepts de Validata : schémas, catalogues, fichiers à valider
- appeler une librairie de validation JSON Schema
- modifier la page de résultats de validation pour ne pas afficher une table, mais un arbre, avec certains nœuds en rouge avec les erreurs
- coder l'appli en Sapper/Svelte pour une meilleure interactivité

Questions:
-

## 2019-10-09 IDéO BFC (Jérome Boutet)

Le call Validata avec [IDéO BFC](https://www.ideobfc.fr/accueil) (un GIP en Bourgogne Franche Comté qui mutualise des ressources pour l'open data) s'est bien passé. Leur prestataire ([Neogeo](https://www.neogeo.fr/) était présent. En gros ils sont en train de faire un nouveau portail (basé en grande partie sur CKAN) et le client veut intégrer la validation de fichiers avec Validata quelque part dans l'IHM mais ne sait pas encore trop comment (avant ou après publication ?). Ils vont y réfléchir et revenir vers nous.
Il se trouve qu'[une extension CKAN existe pour Goodtables](https://github.com/frictionlessdata/ckanext-validation), j'ai suggéré qu'on travaille ensemble à une adaptation pour brancher l'API de Validata.

## 2019-10-04

### Jérôme Boutet - Validata API

> Dans le cadre du développement de notre portail de la donnée, nous souhaitons intégrer l’API de validata.
>
> De la première lecture de la documentation de l’API de la part de notre prestataire ;
>
> https://go.validata.fr/api/v1/apidocs#/default/post_validate
>
> Le schéma à soumettre est une url, qui faut nécessairement connaitre, et donc « inscrire en dur » pour notre future intégration.
>
> Ce qui nécessiterait une maintenance à chaque itération (de nouveaux schémas du scdl), et les écrire dans notre instance…
>
> Est-ce qu’il est prévu de faire évoluer Validata et notamment l’API ?
>
> Si oui, nous pourrons peut être contribuer à cette évolution, afin de faciliter l’intégration au sein de notre projet.

Réponse (en cours) :

> Merci pour la prise de contact qui va permettre de faire progresser Validata pour aller dans le sens d'une meilleure appropriation de l'API par des tiers. Je te confirme que c'est bien là notre objectif. Mais, jusqu'à présent, le seul utilisateur de l'API c'est nous ou plutôt l'UI de Validata, donc la documentation n'est pas encore au niveau...
>
> Je vous propose une réunion téléphonique dans les prochains jours pour que l'on puisse répondre en détails à toutes vos interrogations, et nous tâcherons d'améliorer la doc pour répondre à ce cas d'usage qui, on l'espère !, pourra ainsi être reproduit par d'autres. Quelles seraient vos disponibilités la semaine prochaine ?
>
> En préambule à cela, ce que je peux te dire c'est qu'il faut distinguer Validata API, Validata UI et le référencement des schéma. Par souci de développer une architecture pérenne, modulaire et qui puisse s'adapter à différents besoins, nous avons fait en sorte que l'ensemble soit découplé mais fonctionne en bonne intelligence.
>
> Validata UI s'initialise avec un catalogue de schéma dont l'URL est dans un fichier de config, et qui permet ainsi d'afficher sa propre sélection de schéma dans un menu déroulant sur la page d'accueil.
>
> Validata API, le validateur, prend en input un fichier tabulaire et un schéma Table Schema et qui sort un rapport de validation en JSON
>
> Ce rapport peut être affichée dans Validata UI.
>
> et le Socle commun des données locales, qui est le "catalogue" de schémas qui nécessite sa propre gouvernance (https://git.opendatafrance.net/scdl/catalog).

### Architecture Validata

graph TD

subgraph Validata
    UI["validata-ui"]
    API["validata-api"]
    core["validata-core"]
    UI-config(Configuration)
end

    schema[Schémas]
    catalog[Catalogue de schémas]
    ODS-py[opendataschema-python]
    TS[Spécification<br>Table Schema]
    schema-catalog[Spécification<br>schema-catalog]
    
    UI -- appelle --> API
    API -- utilise --> core
    UI === UI-config
    UI-config -- référence --> catalog
    catalog -- référence --> schema
    UI -- utilise --> ODS-py
    ODS-py -- pour intéragir avec --> catalog
    catalog -- défini par --> schema-catalog

    schema -- défini par --> TS
    core -- utilise --> Goodtables

subgraph FD[Frictionless Data]
    Goodtables -- utilise --> TS
end
    
    click UI "https://git.opendatafrance.net/validata/validata-ui"
    click API "https://git.opendatafrance.net/validata/validata-api/"
    click core "https://git.opendatafrance.net/validata/validata-core/"
    click UI-config "https://git.opendatafrance.net/validata/validata-ui/blob/master/homepage_config.json.example"
    click ODS-py "https://framagit.org/opendataschema/opendataschema-python"
    click TS2M "https://framagit.org/opendataschema/table-schema-to-markdown"
    click Goodtables "https://github.com/frictionlessdata/goodtables-py/"
    click TS "https://frictionlessdata.io/specs/table-schema/"
   click schema-catalog "https://framagit.org/opendataschema/catalog/blob/master/schema-catalog.json"
    

[Mermaid Editor](https://mermaidjs.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoiZ3JhcGggVERcblxuc3ViZ3JhcGggVmFsaWRhdGFcbiAgICBVSVtcInZhbGlkYXRhLXVpXCJdXG4gICAgQVBJW1widmFsaWRhdGEtYXBpXCJdXG4gICAgY29yZVtcInZhbGlkYXRhLWNvcmVcIl1cbiAgICBVSS1jb25maWcoQ29uZmlndXJhdGlvbilcbmVuZFxuXG4gICAgc2NoZW1hW1NjaMOpbWFzXVxuICAgIGNhdGFsb2dbQ2F0YWxvZ3VlIGRlIHNjaMOpbWFzXVxuICAgIE9EUy1weVtvcGVuZGF0YXNjaGVtYS1weXRob25dXG4gICAgVFNbU3DDqWNpZmljYXRpb248YnI-VGFibGUgU2NoZW1hXVxuICAgIHNjaGVtYS1jYXRhbG9nW1Nww6ljaWZpY2F0aW9uPGJyPnNjaGVtYS1jYXRhbG9nXVxuICAgIFxuICAgIFVJIC0tIGFwcGVsbGUgLS0-IEFQSVxuICAgIEFQSSAtLSB1dGlsaXNlIC0tPiBjb3JlXG4gICAgVUkgPT09IFVJLWNvbmZpZ1xuICAgIFVJLWNvbmZpZyAtLSByw6lmw6lyZW5jZSAtLT4gY2F0YWxvZ1xuICAgIGNhdGFsb2cgLS0gcsOpZsOpcmVuY2UgLS0-IHNjaGVtYVxuICAgIFVJIC0tIHV0aWxpc2UgLS0-IE9EUy1weVxuICAgIE9EUy1weSAtLSBwb3VyIGludMOpcmFnaXIgYXZlYyAtLT4gY2F0YWxvZ1xuICAgIGNhdGFsb2cgLS0gZMOpZmluaSBwYXIgLS0-IHNjaGVtYS1jYXRhbG9nXG5cbiAgICBzY2hlbWEgLS0gZMOpZmluaSBwYXIgLS0-IFRTXG4gICAgY29yZSAtLSB1dGlsaXNlIC0tPiBHb29kdGFibGVzXG5cbnN1YmdyYXBoIEZEW0ZyaWN0aW9ubGVzcyBEYXRhXVxuICAgIEdvb2R0YWJsZXMgLS0gdXRpbGlzZSAtLT4gVFNcbmVuZFxuICAgIFxuICAgIGNsaWNrIFVJIFwiaHR0cHM6Ly9naXQub3BlbmRhdGFmcmFuY2UubmV0L3ZhbGlkYXRhL3ZhbGlkYXRhLXVpXCJcbiAgICBjbGljayBBUEkgXCJodHRwczovL2dpdC5vcGVuZGF0YWZyYW5jZS5uZXQvdmFsaWRhdGEvdmFsaWRhdGEtYXBpL1wiXG4gICAgY2xpY2sgY29yZSBcImh0dHBzOi8vZ2l0Lm9wZW5kYXRhZnJhbmNlLm5ldC92YWxpZGF0YS92YWxpZGF0YS1jb3JlL1wiXG4gICAgY2xpY2sgVUktY29uZmlnIFwiaHR0cHM6Ly9naXQub3BlbmRhdGFmcmFuY2UubmV0L3ZhbGlkYXRhL3ZhbGlkYXRhLXVpL2Jsb2IvbWFzdGVyL2hvbWVwYWdlX2NvbmZpZy5qc29uLmV4YW1wbGVcIlxuICAgIGNsaWNrIE9EUy1weSBcImh0dHBzOi8vZnJhbWFnaXQub3JnL29wZW5kYXRhc2NoZW1hL29wZW5kYXRhc2NoZW1hLXB5dGhvblwiXG4gICAgY2xpY2sgVFMyTSBcImh0dHBzOi8vZnJhbWFnaXQub3JnL29wZW5kYXRhc2NoZW1hL3RhYmxlLXNjaGVtYS10by1tYXJrZG93blwiXG4gICAgY2xpY2sgR29vZHRhYmxlcyBcImh0dHBzOi8vZ2l0aHViLmNvbS9mcmljdGlvbmxlc3NkYXRhL2dvb2R0YWJsZXMtcHkvXCJcbiAgICBjbGljayBUUyBcImh0dHBzOi8vZnJpY3Rpb25sZXNzZGF0YS5pby9zcGVjcy90YWJsZS1zY2hlbWEvXCJcbiAgIGNsaWNrIHNjaGVtYS1jYXRhbG9nIFwiaHR0cHM6Ly9mcmFtYWdpdC5vcmcvb3BlbmRhdGFzY2hlbWEvY2F0YWxvZy9ibG9iL21hc3Rlci9zY2hlbWEtY2F0YWxvZy5qc29uXCIiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9fQ)

### Implémentations existantes

- OpenDataFrance
- Instance de Validata : https://go.validata.fr/
- Catalogue de schémas : [SCDL](https://scdl.opendatafrance.net/) ([fichier source](https://git.opendatafrance.net/scdl/catalog/blob/master/catalog.json))
- Etalab
- Instance de Validata : https://validata.etalab.studio/
- Catalogue de schémas : [schema.data.gouv.fr](https://schema.data.gouv.fr/) ([fichier source](https://github.com/etalab/schema.data.gouv.fr/blob/master/aggregateur/data/schemas.json))

### SCDL

graph TD

subgraph Documentation[Documentation du SCDL]

    siteSCDL[scdl.opendatafrance.net]
    doc[SCDL/documentation]
    Markdown[Fichiers de documentation Markdown]
end

    catalog[Catalogue de schémas du SCDL]
    schema[Schémas du SCDL]
    TS2M[table-schema-to-markdown]
    ODS-py[opendataschema-python]
    
    siteSCDL -- est propulsé par --> doc
    doc -- utilise --> ODS-py
    ODS-py -- pour intéragir avec --> catalog  
    doc -- contient --> Markdown
    doc -- utilise --> Gitbook
    Markdown -- générés avec --> TS2M
    TS2M -- à partir de --> schema

    catalog -- référence --> schema

    click siteSCDL "https://scdl.opendatafrance.net/"
    click catalog "https://git.opendatafrance.net/scdl/catalog"
    click doc "https://git.opendatafrance.net/scdl/documentation"
    click ODS-py "https://framagit.org/opendataschema/opendataschema-python"
    click TS2M "https://framagit.org/opendataschema/table-schema-to-markdown"

Archives :
- [diagramme nouvelle version, tout en un](https://mermaidjs.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoiZ3JhcGggVERcblxuICAgIFRTMk1bdGFibGUtc2NoZW1hLXRvLW1hcmtkb3duPGJyPkfDqW7DqXJhdGlvbiBkZSBmaWNoaWVycyBNYXJrZG93biDDoCBwYXJ0aXIgZGUgVGFibGUgU2NoZW1hXVxuICAgIE9EU3B5W29wZW5kYXRhc2NoZW1hLXB5dGhvbjxicj5NYW5pcHVsYXRpb24gZGUgY2F0YWxvZ3VlIGRlIHNjaMOpbWFzXVxuICAgIFxuICAgIEdPIC0tIGVzdCBwcm9wdWxzw6llIHBhciAtLT4gVUlcbiAgICBVSSAtLSBhcHBlbGxlIC0tPiBBUElcbiAgICBVSSAtLSBhcHBlbGxlIC0tPiBjYXRhbG9nXG4gICAgVUkgLS0gdXRpbGlzZSAtLT4gT0RTcHlcbiAgICBBUEkgLS0gZMOpcGVuZCBkZSAtLT4gY29yZVxuICAgIGRvY1NDREwgLS0gZXN0IHByb3B1bHPDqWUgcGFyIC0tPiBkb2NcbiAgICBkb2MgLS0gYXBwZWxsZSAtLT4gY2F0YWxvZ1xuICAgIGRvYyAtLSB1dGlsaXNlIC0tPiBUUzJNXG4gICAgZG9jIC0tIHV0aWxpc2UgLS0-IE9EU3B5XG4gICAgY2F0YWxvZ1xuICAgIGNhdGFsb2cgLS0gcsOpZsOpcmVuY2UgbGVzIHNjaMOpbWFzIC0tPiBzY2hlbWFcbiAgICBjb3JlIC0tIGTDqXBlbmQgZGUgLS0-IEdvb2R0YWJsZXNcblxuc3ViZ3JhcGggVmFsaWRhdGFcbiAgICBHT1tJbnN0YW5jZSBkZSBWYWxpZGF0YV1cbiAgICBVSVt2YWxpZGF0YS11aTxicj5JbnRlcmZhY2UgZGUgVmFsaWRhdGFdXG4gICAgQVBJW3ZhbGlkYXRhLWFwaTxicj5BUEkgZGUgVmFsaWRhdGFdXG4gICAgY29yZVt2YWxpZGF0YS1jb3JlXVxuZW5kXG5cbnN1YmdyYXBoIFNDRExcbiAgICBkb2NTQ0RMW3NjZGwub3BlbmRhdGFmcmFuY2UubmV0PGJyPkRvY3VtZW50YXRpb24gZGVzIHNjaMOpbWFzIGR1IFNDRExdXG4gICAgZG9jW2RvY3VtZW50YXRpb248YnI-RmljaGllcnMgTWFya2Rvd25dXG4gICAgY2F0YWxvZ1tjYXRhbG9nLmpzb248YnI-Q2F0YWxvZ3VlIGRlIHNjaMOpbWFzXVxuICAgIHNjaGVtYVtzY2hlbWEuanNvbjxicj5Ew6lww7R0IGdpdCBkJ3VuIHNjaMOpbWFdXG5lbmRcblxuc3ViZ3JhcGggRkRbRnJpY3Rpb25sZXNzIERhdGFdXG4gICAgR29vZHRhYmxlcyAtLSBkw6lwZW5kIGRlIC0tPiBUYWJsZVNjaGVtYVxuZW5kIiwibWVybWFpZCI6eyJ0aGVtZSI6ImRlZmF1bHQifX0)
- [diagramme ancienne version](https://mermaidjs.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoiZ3JhcGggVEQ7XG4gICAgaWRHT1tcIjxiPmdvLnZhbGlkYXRhLmZyPC9iPlwiXSAtLSBlc3QgcHJvcHVsc8OpIHBhciAtLT5pZFZVW1wiPGI-dmFsaWRhdGEtdWk8L2I-XCJdO1xuICAgIGlkVlUtLSBhcHBlbGxlIC0tPiBpZFZBW1wiPGI-dmFsaWRhdGEtYXBpPC9iPlwiXTtcbiAgICBpZFZBLS0gZMOpcGVuZCBkZSAtLT5pZFZDW1wiPGI-dmFsaWRhdGEtY29yZTwvYj48YnIvPnNjaGVtYXMudG9tbFwiXTtcbiAgICBpZFNDRExbXCI8Yj5zY2RsLm9wZW5kYXRhZnJhbmNlLm5ldDwvYj48YnIvPkRvY3VtZW50YXRpb24gZGVzIHNjaMOpbWFzXCJdLS0gZXN0IHByb3B1bHPDqSBwYXIgLS0-aWRWRDtcbiAgICBpZFZEW1wiPGI-dmFsaWRhdGEtZG9jPC9iPjxici8-R2l0Ym9va1wiXS0tIGVzdCBnw6luw6lyw6kgcGFyIC0tPmlkVkRHO1xuICAgIGlkVkRHW1wiPGI-dmFsaWRhdGEtZG9jLWdlbmVyYXRvcjwvYj48YnIvPihHw6luw6hyZSB1biBmaWNoaWVyIE1hcmtkb3duIMOgIHBhcnRpciBkJ3VuIHNjaGVtYS5qc29uKVwiXS0tIGTDqXBlbmQgZGUgLS0-aWRWQztcbiAgICBcbiAgICBpZFZDLS0gcsOpZsOpcmVuY2UgbGVzIHNjaMOpbWFzIC0tPiBpZDFbXCI8Yj5Ew6lww7R0IGdpdCBkJ3VuIHNjaMOpbWE8L2I-PGJyLz5zY2hlbWEuanNvbjxici8-Q09OVEVYVEUubWQ8YnIvPlNFRV9BTFNPLm1kPGJyLz5GaWNoaWVycyBleGVtcGxlc1wiXTtcblxuICAgIHN1YmdyYXBoIEZyaWN0aW9ubGVzcyBEYXRhXG4gICAgICAgIGlkR1RbXCJHb29kdGFibGVzXCJdO1xuICAgICAgICBpZEdULS0gZMOpcGVuZCBkZSAtLT5UYWJsZVNjaGVtYTtcbiAgICBlbmRcblxuICAgIGlkVkMtLSBkw6lwZW5kIGRlIC0tPmlkR1Q7IiwibWVybWFpZCI6eyJ0aGVtZSI6ImRlZmF1bHQifX0)