[SCHEMA] Consolidate schema files by term type#883
[SCHEMA] Consolidate schema files by term type#883tsalo merged 20 commits intobids-standard:masterfrom
Conversation
Still need to document the rules files.
| @@ -1,5 +1,5 @@ | |||
| --- | |||
There was a problem hiding this comment.
These datatypes files are essentially unchanged. I didn't come up with a clean way to reorganize them.
There was a problem hiding this comment.
I did end up changing the indents for lists because apparently yamllint's default behavior doesn't match libyaml's defaults. I don't think there's even an easy way to write out lists with that extra indent with pyyaml, so this should make it easier to write out schema files programmatically in the future.
| @@ -0,0 +1,27 @@ | |||
| --- | |||
There was a problem hiding this comment.
This is a new "rules" file for entities.
|
Given the ~400 files that are removed or just moved, I've added comments to the most relevant ones. EDIT: It turns out there's an option to hide deleted files under "File filters" that I was previously unaware of, so that should help. |
| as `type`: `minItems`, `maxItems`. | ||
| Here is an example of a field that MUST have three `integer` items: | ||
| ```yaml | ||
| The schema is divided into two parts: the object definitions and the rules. |
There was a problem hiding this comment.
Is this documentation clear enough?
There was a problem hiding this comment.
I think so. Definitely helped me at least.
|
Tagging @bids-standard/schema-users. Is this going to cause any major problems for any tools that use the schema? |
Looks like just path updates needed for bids-validator but otherwise it looks compatible with the use case so far. |
|
I haven't finalized any schema related code yet at |
effigies
left a comment
There was a problem hiding this comment.
LGTM. Small suggestions.
The datatype descriptions. Co-authored-by: Chris Markiewicz <effigies@gmail.com>
Make utility functions public. Co-authored-by: Chris Markiewicz <effigies@gmail.com>
src/schema/README.md
Outdated
| The `type` field defines the representation type for the value associated with the entity. | ||
| All entities are represented in filenames as key-value pairs, and in all cases the value should be a string, | ||
| so the `type` field should always be `string`. |
There was a problem hiding this comment.
Maybe give an example here because on its own, I find this confusing.
There was a problem hiding this comment.
I rewrote this portion in 70e2c4e. I hope it's clearer now.
| MUST have a corresponding `Density` metadata field to provide | ||
| interpretation. | ||
|
|
||
| This entity is only applicable to derivative data. |
There was a problem hiding this comment.
Side note: I suspect you have thought about this, but we might need at some point to create a rule to keep track of derivatives only entities.
There was a problem hiding this comment.
You're right. We can always add whatever fields we want, but it's probably something that can be formalized with the changes proposed by @erdalkaraca in #884.
| as `type`: `minItems`, `maxItems`. | ||
| Here is an example of a field that MUST have three `integer` items: | ||
| ```yaml | ||
| The schema is divided into two parts: the object definitions and the rules. |
There was a problem hiding this comment.
I think so. Definitely helped me at least.
Thanks @Remi-Gau! Co-authored-by: Remi Gau <remi_gau@hotmail.com>
|
Now that we have two approvals and I think I've addressed the review comments, I believe this is ready to merge. Do we want to wait five days before merging? |
Technically this does not affect the content itself so I am not sure if the 5 days rule apply. https://github.com/bids-standard/bids-specification/blob/master/DECISION-MAKING.md#rules I know that there have been precedents for infra related PR where we merged sooner than that. @sappelhoff @effigies |
|
I haven't had a chance to take a look yet, but yeah - if no content is impacted and most major schema-stakeholders agree, then I think merging is fine |
|
Well, I pinged the schema users team 11 days ago and no one raised any concerns, so I guess I'll merge once CI finishes. Thanks! |
I definitely made a mistake in bids-standard#883.
* Add new MEG structure. * Document new rules format. * Support the new structure in the code. * Fix entity tables bug. I definitely made a mistake in #883. * Clean up code. * Fix the entity table more. * Drop unnecessary MEG group. * Try something. * Handle arbitrary numbers of rows and just use duplicate name. * Forgot to revert the import change.
…les/raw Was suggestsed in one of the files within https://github.com/bids-standard/bids-specification/pull/1128/files#diff-374b38cbccac62b8efa8e4ab2552cf9be8ba9eff7c45025abfc6da27d461a37b and is needed to the recent refactoring done in 251f440 (bids-standard#883) === Do not change lines below === { "chain": [], "cmd": "git-sedi 'rules\\/datatypes' 'rules\\/files\\/raw'", "exit": 0, "extra_inputs": [], "inputs": [], "outputs": [], "pwd": "." } ^^^ Do not change lines above ^^^
…les/raw (#1362) Was suggestsed in one of the files within https://github.com/bids-standard/bids-specification/pull/1128/files#diff-374b38cbccac62b8efa8e4ab2552cf9be8ba9eff7c45025abfc6da27d461a37b and is needed to the recent refactoring done in 251f440 (#883) === Do not change lines below === { "chain": [], "cmd": "git-sedi 'rules\\/datatypes' 'rules\\/files\\/raw'", "exit": 0, "extra_inputs": [], "inputs": [], "outputs": [], "pwd": "." } ^^^ Do not change lines above ^^^
Closes #877 and closes #603.
Changes proposed: