165 scene/state

[kaitlyn-sharo]

Created a script that will generate two api files from the swagger api. The first is a slightly modified copy of the swagger api that has some removed properties and a few more required properties. The second is a state_change api that removes many of the required properties from scenes/state. This PR also incorporates that state_change file into the validation. To test:

python3 validator.py -f test.yaml --update

Message from Darren that this PR is based on.

API vs. Validator required differences:

• Scenario validator requires Scenario.scenes; API does not;
• Scenario validator requires Action.probe_id and Action.choice; API does not;
• Scenario validator requires all Vitals properties to be specified; API does not.
• Valid values for InjuryStatusEnum should only be hidden, discoverable, or visible. The others are only used at runtime by the server.

There are a few properties that are allowed in the API but not in the validator:

• Action.justification
• Character.visited
• Scenario.session_complete
• State.scenario_complete and State.elapsed_time
• NOTE: Scenario.start_time (wall clock local start time) used to exist in the API, but as it's not clear it's needed or used, I was thinking to remove it...

When validating Scenes.state:

• Only State.unstructured is required in State
• If State.mission is included, then only Mission.unstructured is required
• If State.environment is included, then Environment.sim_environment isn't required (i.e., nothing is)
• If Environment.sim_environment is included, then SimEnvironment.unstructured should be required (and type should be forbidden, but that's for later)
• If Environment.decision_environment is included, then DecisionEnvironment.unstructured should be required
• If DecisionEnvironment.aid_delay is included, then nothing should be required
• Other than that, validation is the same as for initial state.

[kaitlyn-sharo]

Everything looks super-solid. All of the rules seem to work. One very minor thing and a new rule to add, but otherwise ready to go.

I did have one more question-- there's an argument not to check in state_changes.yaml into source control because it's a generated file. But I don't think there's anything wrong with checking it in, and prevents you from having to generate it the first time around, especially since there's no dependency set up where running the validator will generate the file if it's not already there. So I think we're good-- I just wanted to mention it.

Yes, that's a good point about state_changes.yaml. I think that since we're going to be handing this to TA1, we want to reduce the amount of steps we hand them, so it would probably be nicest to just keep the two generated yaml files there so that they don't have to run it every time or worry about additional switches.