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?
parameters_meta_schema.json
Outdated
| "allTypes": { | ||
| "type": ["integer", "boolean", "number", "string", "null"] | ||
| }, |
There was a problem hiding this comment.
How is this different to the one above?
There was a problem hiding this comment.
The above one is a definition that states the value should be a string of one of these: "string", "boolean", "integer", "number" or "null".
The bottom one states that value should be one of those types. (It's just a shortcut I wrote to keep the redundancy as low as I could)
There was a problem hiding this comment.
Gotcha 👍🏻 Can you reference this above as well so that there's only one set, out of interest? I guess not as it needs a $ref key and that'd break the array structure.. 🤔
There was a problem hiding this comment.
I'm not sure I'm following what you mean here 😁
|
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? |
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)