mobility-data-specification icon indicating copy to clipboard operation
mobility-data-specification copied to clipboard

Policy API: Clarify Rules.states description field

Open billdirks opened this issue 4 years ago • 0 comments

Is your feature request related to a problem? Please describe.

I find the description of Rules.states in MDS 1 to be unclear.

In MDS <1 the language for matching a status change to a rule.states object was clear since a status change could only have 1 event_type_reason and rule.states was a list. That is, a status change would match a rule if the rule.states[status_changed.event_type] was null/empty or the status change's event_type_reason could be found in the non-empty list returned from rule.states[status_changed.event_type].

In MDS 1 the matching rule is less clear since the status change's event_type and the rule.states[status_changed.vehicle_state] could both be lists. For example, assuming the rule.states[status_changed.vehicle_state] is a nonempty list, does the status change match if its event_types are all in the rule.states[vehicle_state] list or if at least one of them is in this list?

In more detail:

  1. Policies could be written to specify a node of the state machine and an incoming edge. If this is true it would be good to change the language of the rule.states description to say that the rule applies to a status change if the rule.states list for the status change's state is null/empty or is non-null/non-empty and is non-disjoint with the status change's event_type.

  2. If the intent is for all the status change's event_types to found in the rules.states[vehicle_state] list, this should be explicitly stated. This would correspond to specifying a policy over a status change with a particular end state that contained multiple specific state transitions.

Describe the solution you'd like

To me it seems like 1 is the desired behavior.

Is this a breaking change

  • I'm not sure

While this isn't incompatible with the current specification, I believe the current specification is unclear so refining language could be inconsistent with someone's implementation.

Impacted Spec

  • policy

Describe alternatives you've considered

See 1 and 2 above.

billdirks avatar Aug 05 '21 20:08 billdirks