-
Notifications
You must be signed in to change notification settings - Fork 0
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
Cleanup JSON schemas and add ADR #174
Conversation
911f8f7
to
3701b93
Compare
|
||
To ensure we capture and preserve the context of LPAs, each LPA will be associated with a JSON schema at point of execution (online) or ingestion (paper). That schema will document the shape of the LPA's data. | ||
|
||
The schema file will be mapped to translation files that contain any important text associated with the LPA, such as the terms the donor agreed to. There will be a file for each language a donor can use (currently English or Welsh). |
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.
should this also say something about the decision made that the language signed in is assumed to be the same as the contactLanguagePreference for the donor?
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.
I wasn't sure if we'd landed on a definitive answer for that yet so didn't want to specify it in here
`lpa.json` is now the full LPA structure. `submitted-lpa.json` is the subset of fields that should initially be initially submitted from MRLPA or scanning. Create `translation.*.json` to indicated what translation files might look like/contain. Add an ADR documenting how we will use, host and version our JSON schemas. #minor
- Use date-time in schema to reflect existing code - Use "donorTerms" rather than "terms" #patch
3701b93
to
47fd963
Compare
docs/architecture/decisions/0004-use-json-schemas-to-define-lpa-structure.md
Show resolved
Hide resolved
|
||
As validation is currently done manually, there is a risk that the structure of the LPA will not match the JSON schema. We should introduce schema validation when storing an LPA to ensure this is not the case. | ||
|
||
We need to ensure that any changes to the structure of the data are properly updated in the schema. An exception to this is before the start of private beta, since we will only be working with test data and can more easily change the schema. |
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.
Probably need to add something about what the intended process is for proposing new schema versions. i.e. must have clear intent and cross-team ratification (via PR?)
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.
I've added a bit more about this, but I don't want to get into too much specification since I don't have a strong feeling of how this will work best. I think as we see how this works into products we'll be able to define what structure and safeguards we need.
Aligns better with MRLPA and Sirius language, and is a bit clearer about it contents. #patch
For easier management between languages #patch
#patch
"InitialLpa" -> "DonorDetails" #patch
204f1cc
to
7e88fef
Compare
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.
lpa.json
is now the full LPA structure.submitted-lpa.json
is the subset of fields that should initially be initially submitted from MRLPA or scanning.Create
translation.*.json
to indicated what translation files might look like/contain.Add an ADR documenting how we will use, host and version our JSON schemas.
#minor