-
Notifications
You must be signed in to change notification settings - Fork 38
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
Add JSON schemas for plate and well specification #120
Conversation
At the moment, each test suite is creating its own internal schema store with a single schema. This prevents the testing combined schemas like the strict schemas either when the parent schema is unpublished or simply offline. This commit migrates the logic to create a single global schema store
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments aside, this all looks fine to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I assume you want to capture any changes/clarifications to the text in follow ups, no?
If we are all fine with the current state, next todos were: 1- update the text of the Doing this as separate follow-up PRs has the benefit of iterating quicker. |
Similarly to what has been done for
multiscales
, this PR introduced four new JSON schemas to the 0.4 specification:plate.schema
which should enforce the mandatory properties (MUST) of theplate
specificationstrict_plate.schema
which extendsplate.schema
and enforces the recommended properties (SHOULD).well.schema
which should enforce the mandatory properties (MUST) of thewell
specificationstrict_well.schema
which extendswell.schema
and enforces the recommended properties (SHOULD).Tests formatted using the JSON schema test suite layout are added and the example snippets are extracted under
examples
using the similar logic as #118.Two modifications of the validation tests were required. e49f126 ensures only the examples located in the same folder as
.config.json
are tested against a given schema. 949a352 creates a shared schema store. Since the strict schemas are referencing other schemas via$ref
, this store is required to allow the test the local versions under/schemas
. Otherwise, the tests will try to resolve remote schemas which would fail either if working offline or when working with unpublished schemas.The specification of the JSON schema required a few assumptions that are currently underspecified:
rows
,columns
andwells
are the only mandatory properties ofplate
name
andversion
are recommended properties ofplate
plate
properties are optionalid
of each element of theacquisitions
array is an integerstarttime
andendtime
of each element of theacquisitions
array is an integer-
version
is a recommended property ofwell
Probably the biggest inconsistency identified by this schema work is about the type of
acquisition.starttime
andacquisition.endtime
which is marked as "epoch string" in the specification text while the JSON examples use integers.