New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future possibility for delimiter-separated list for arrays (instead of JSON array)? #736
Comments
We discussed it in Discord and I think that
might make sense for the specs |
FWIW, I have had some feedback from users who would possibly appreciate to have a non-comma separator (e.g. Thanks for considering this, it would be great to have and would let us clean a few schemas! |
I'm currently working on a PR to integrate this. I've made the relevant changes in Currently I'm getting this error (below), which I can get rid of if I remove the Where should I be looking to add this to the schema? |
@AyrtonB |
That makes sense, I'll do that |
I'll continue discussion around specifics of this implementation in the PR linked above |
Is is already possible to specify arrays without the square brackets? I would say it is the normal case for CSV files. You have a value like |
Hi, I've created a feature request for the framework to pilot the feature: |
I'm a colleague of @geoffreyaldebert, working on a French national CSV schema for "bikes counting" at the moment.
My understanding is that #712 frictionlessdata/frictionless-py#627 introduced a way to restrict allowed values in an array, which is neat.
In our case (based on input from future data producers and reusers), we would like to avoid using JSON arrays for those values, and instead use delimiter-separated values, which are less complicated to write and decode without troubles for less technical users.
The rationale is that we are creating a CSV schema to avoid JSON in the first place, which some users find confusing with their current level of technicality, to drive adoption.
Our current solution (WIP, the schema is not published yet) is to use a regex pattern:
https://github.com/etalab/schema-comptage-velo/blob/15096e6145b4926530a6fc5126db8cd25e35c803/schema.json#L175-L184
It is a trick commonly used before for that case (e.g. https://schema.data.gouv.fr/etalab/schema-inclusion-numerique/latest/documentation.html#propriété-public_cible).
So my question is: is there room to consider future evolutions to add a "CSV-array" column type, with restrictions on actual values to be in an allowed range?
Thanks!
The text was updated successfully, but these errors were encountered: