Continuing discussion which started in #475 but should be handled (some time after #475 is merged and a new BIDS spec version released).
My thinking as for moving support code to bids-schema was -- to facilitate access (for code) to previous versions of schema so validators etc could validate against actual schema version, instead of the most recent or whatever single one they have available; and also schema access API/code could be tested against older versions etc. Actually probably not all code should migrate -- schema access code/API -- migrate. Helpers to "render markdown" -- should reside here since that is where they are most pertinent and not needed for 3rd party applications wanting to access schema itself.
While actual "current" schema would reside here (and only archived upon release to bids-schema), released code should not need changes for schema/docs changes in BIDS itself. Any changes to code to render data within bids-specification would then done in this repository.
There will be cases were code changes would be necessary to accommodate new desires in the schema itself! For those developments it should be relatively easy to establish a branch within bids-schema with needed changes in the code, while working also here on actual schema changes. It just would need bids-schema code release before PR here would be merged. A bit cumbersome... but could work.
Having said all that, I think all code should reside here at least for some time so that schema and code "solidify" a bit more...
Alternative: do not move code at all, and rather
- make
bids-specification itself into providing a python package (bids_schema) with the API
- might require releases of
bids_schema python package code without releasing bids-specification itself
although sounds simple(r) I think such a mix of code + specification might eventually bite back painfully.
Continuing discussion which started in #475 but should be handled (some time after #475 is merged and a new BIDS spec version released).
My thinking as for moving support code to
bids-schemawas -- to facilitate access (for code) to previous versions of schema so validators etc could validate against actual schema version, instead of the most recent or whatever single one they have available; and also schema access API/code could be tested against older versions etc. Actually probably not all code should migrate -- schema access code/API -- migrate. Helpers to "render markdown" -- should reside here since that is where they are most pertinent and not needed for 3rd party applications wanting to access schema itself.While actual "current" schema would reside here (and only archived upon release to
bids-schema), released code should not need changes for schema/docs changes in BIDS itself. Any changes to code to render data within bids-specification would then done in this repository.There will be cases were code changes would be necessary to accommodate new desires in the schema itself! For those developments it should be relatively easy to establish a branch within
bids-schemawith needed changes in the code, while working also here on actual schema changes. It just would needbids-schemacode release before PR here would be merged. A bit cumbersome... but could work.Having said all that, I think all code should reside here at least for some time so that schema and code "solidify" a bit more...
Alternative: do not move code at all, and rather
bids-specificationitself into providing a python package (bids_schema) with the APIbids_schemapython package code without releasingbids-specificationitselfalthough sounds simple(r) I think such a mix of code + specification might eventually bite back painfully.