-
Notifications
You must be signed in to change notification settings - Fork 231
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
JSON Schemas for the Policy Endpoints #389
Comments
I forget who was going to take ownership of it. I won't have time to do it by Sunday. Can we kick this over to City Services and say that Agency and Provider 0.4.1 have a little more time? My feeling is that as long as we get it done sufficiently ahead of April 1, the tech council and board will still have time to review and approve all in one go at that time. |
Not that any of this would be controversial for the Tech Council... but I think the main issue is how we advertise the RC on Sunday and package what is ready for review by the Tech Council - by tagging |
Is there a reason this has to go into 0.4.1? Would rather get our releases out the door on time than hold for a specific feature unless critical. |
It can wait. |
@Karcass I started to work on these schemas in a personal branch - I can push this up when it's a little more complete. Moving from 0.4.1 Milestone for now. |
I dropped this into 1.0.0, since we should probably try to get this taken care of sooner rather than later. |
👍 this again, it would really good idea to have this to validate policies / geographies as systems / cities are generating them. |
@Karcass @thekaveman Do you think this could be ready for 1.0.0? |
I think we gotta do it. I'm no good at this stuff though. |
Moved as a project for the next release since there is lots of other schema work going on with the reconciliation. |
I'm working on this, planning to have something up for review in the next week or so. |
A couple of questions after digging into the field definitions and examples. /cc @hunterowens @Karcass @schnuerle @ascherkus @quicklywilliam Rule type
|
Name | Rule Types | Description |
---|---|---|
info |
user |
Information only, intended for the user |
Solution 2: Make rule_unit
conditionally required depending on the value of rule_type
.
For rule_type: user
the rule_unit
field could be omitted.
Or something else?
Optional fields: null
or not.
Many of the Policy and Rule fields are optional, but it's not clear whether this means null
should be supported as a value, or if the preference is for the key/value to be omitted, or to allow for both (maybe per field).
This is probably a question for MDS schemas at large; Provider also defines a mix of optional fields, some which allow and some which do not allow null
. Though most optional fields tend towards disallowing null
in existing schemas across MDS. Deciding on a single approach would be useful.
The Policy examples use a mix of styles; end_date
is presented as null
, whereas many other optional fields are omitted.
Is there a per-field preference for Policy/Rule? I would suggest disallowing null
on optional fields, favoring the omission of the key/value.
We discussed these open questions on the 9/3 City Services call. Rule type
|
Fixed with #576 |
Describe the bug
not including JSON Schema in #382, so we can iterate faster on the draft during the 0.4.1 cycle. at some point during 0.4.1, need to have that created.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
we generate the JSON schemas for policy by running
python schema/generate_schemas.py
.Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: