Update meta schema #30
Conversation
parameters_meta_schema.json
Outdated
| "enum": ["file-path", "directory-path", "path", "file-path-pattern"] | ||
| "enum": [ | ||
| "file-path", | ||
| "directory-path", | ||
| "path", | ||
| "file-path-pattern", | ||
| "date-time", | ||
| "date", | ||
| "time", | ||
| "duration", | ||
| "email", | ||
| "idn-email", | ||
| "hostname", | ||
| "id-hostname", | ||
| "ipv4", | ||
| "ipv6", | ||
| "uuid", | ||
| "uri", | ||
| "uri-reference", | ||
| "iri", | ||
| "iri-reference", | ||
| "uri-template", | ||
| "json-pointer", | ||
| "regex" | ||
| ] |
There was a problem hiding this comment.
I don't think that we do want all of these though.
Although JSON schema libraries can validate them, the launch form / schema builder / other tooling wouldn't know what to do with them.
Not sure that there's any point allowing them for validation if they will break other tooling. Any of these things can still be set as a string without format being set.
There was a problem hiding this comment.
I'm not sure having the other tooling break on an unknown format is that great of an idea. Maybe they should just ignore the formats that are unknown. Some of these formats could be really useful for nextflow pipelines I think (regex, email and uri to name a few). Although I do agree that some don't make any sense to be in here.
There was a problem hiding this comment.
I'm not sure having the other tooling break on an unknown format is that great of an idea.
If they're listed here then other tooling would accept the schema but then not know what to do with the format and either ignore it or break. So I'm suggesting slimming it down for the same reason 😅
My expectation of how this will work is that tools will check the schema against the meta schema and show a warning if it fails. So for example:
Warning: Schema seems invalid - value 'ipv6' not allowed for 'format'
It would then hopefully still continue to try to use the schema as best it can. Which I think is better than including them all, not knowing in advance, and then breaking.
There was a problem hiding this comment.
Okay so I think these make the most sense to keep:
[
"file-path",
"directory-path",
"path",
"file-path-pattern",
"date-time",
"date",
"time",
"email",
"uri",
"regex"
]
Do you agree or should I also remove the ones that aren't built-in to the plugin?
|
Note to self: Use this site to test the meta schema with as much examples as possible: https://www.jsonschemavalidator.net/ |
|
@ewels I think the schema is ready now. Just one thing left: do we want to support nested parameters right now too or should we keep this for later? |
…-meta-schema # Conflicts: # parameters_meta_schema.json
…nested schemas" This reverts commit 2b52366.
Co-authored by: Nicolas Vannieuwkerke <[email protected]>
|
This has been moved to https://github.com/nextflow-io/schema-spec |
This PR updates the meta schema to work with the new features introduced in JSON schema draft
2020-12.Stuff that still needs to be done:
anyOf,allOf,oneOf,if,thenandelse(https://json-schema.org/understanding-json-schema/reference/conditionals)dependentSchema(https://json-schema.org/understanding-json-schema/reference/conditionals)