JSON Schemas for the Policy Endpoints

[hunterowens]

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.

[thekaveman]

@HenriJ @karcass do we anticipate this being ready for 0.4.1 or should we punt further?

[marie-x]

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.

[thekaveman]

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 dev and creating a preliminary Release in GitHub. If this isn't ready in time for that RC, then I think we'll want to wait for the next cycle.

[jfh01]

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.

[marie-x]

It can wait.

[thekaveman]

@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.

[jfh01]

I dropped this into 1.0.0, since we should probably try to get this taken care of sooner rather than later.

[hunterowens]

👍 this again, it would really good idea to have this to validate policies / geographies as systems / cities are generating them.

[schnuerle]

@karcass @thekaveman Do you think this could be ready for 1.0.0?

[marie-x]

I think we gotta do it. I'm no good at this stuff though.

[schnuerle]

Moved as a project for the next release since there is lots of other schema work going on with the reconciliation.

[thekaveman]

I'm working on this, planning to have something up for review in the next week or so.

[thekaveman]

A couple of questions after digging into the field definitions and examples.

/cc @hunterowens @karcass @schnuerle @ascherkus @quicklywilliam

Rule type user rule units

Related to a discussion started in #434.

Policy Rule field rule_type is required, and one of the options is user

Policy Rule field rule_units is also required, and lists a table of options based on the value of rule_type; the table lacks any value for rule_type: user

Solution 1: add something generic like

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.

[thekaveman]

We discussed these open questions on the 9/3 City Services call.

Rule type user rule units

The consensus was to go with Solution 2 above, that is:

Make rule_unit conditionally required depending on the value of rule_type.

For rule_type: user the rule_unit field could be omitted.

Optional fields: null or not.

Since this is a larger issue across MDS, a separate issue has been opened to discuss: #573. Please weigh in there and we'll look to come to a consensus for the next Major release (since likely either choice we make will break somebody).

[schnuerle]

Fixed with #576