mobility-data-specification Policy API's order-of-operations system may have undocumented implications

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

The Policy API has an "order of operations" section, which states:

Rules, being in a list, are ordered most specific to most general. E.g. an "earlier" rule (lower list index) would take precedence over a "later" rule (higher list index).

Rules are a form of pattern matching; conditions under which a given rule is "met" are specified, and a vehicle (or series of vehicles) may match with that rule or set of rules.

If a vehicle is matched with a rule, then it will not be considered in the subsequent evaluation of rules within a given policy.

It seems to me that this means that it would be an error to have multiple rule_types be included in a single Policy.

Here's an example to show what I'm talking about: if a server returned a response that had multiple rule_types within a single Policy, then it seems to me that a client that implemented the letter of the spec would be forced to e.g. ignore a speed rule if the client had previously encountered an applicable count rule earlier in the same Policy.

I don’t think that the spec clearly calls this out. I'm opening this issue so I can confirm that I'm understanding this situation correctly, and so that we can update the spec to make this not-mixing-rule_types constraint clear if it does indeed exist.

Describe the solution you'd like

I think that the "description" section of the rules section of the Policy object's definition should be updated to read something like "List of applicable Rule objects, all of which must have the same rule_type value."

It probably couldn't hurt to mention this constraint a couple of other times throughout the spec, e.g. maybe in the "order of operations" section.

Is this a breaking change

I'm not sure

Impacted Spec

For which spec is this feature being requested?

policy

Describe alternatives you've considered

None at this time

Apr 17 '20 22:04 jrheard

@avatarneil , as discussed during the city-services working group call, please add your use-cases for multiple rule-type policies.

Apr 30 '20 17:04 Retzoh

Hi @jrheard, sorry for not responding earlier, I wanted to take the time to make sure I had a solid response to the issue. I think your understanding of rule-evaluation isn't totally aligned with what the spec is intended to express; the notion of rules taking precedence is meant to apply to the evaluation of the Policy in the context of a particular vehicle, not for a client to ignore rules wholesale.

In the scenario you described, at Compliance evaluation time a client (compliance engine) would pipe the vehicle data (events/telemetry/device info) through the rule set. The evaluation would be ordered, so you would evaluate the vehicles against the rules in order. If they match with the first rule, they are not then considered in evaluation of subsequent rules, and so on. This allows flexibility with how the client interprets the results from each rule -- for example, you could have an initial rule which acts as a "filter" for vehicles before they are evaluated for a subsequent rule.

The question about the mixing of rule_types is super great, thank you for noticing this issue! As I mentioned in the last City Services WG, when we were first throwing around ideas for the Policy spec we went back and forth on the mixing of rule_types a couple times. For the first few passes of Policy as we were prototyping, rule ordering did not matter at all, there was no interaction between one rule and another; this is when the concept of a Policy with multiple rule_types was brought up. A scenario where it could be useful:

You have a parking lot, and you want to express both a vehicle cap + a speed limit + a maximum parking time, all in one policy.

That being said, that policy would make basically no sense because of the implications of rule ordering (you'd get some very strange compliance output). Seems to me like this is totally an artifact of us adding some functionality while brainstorming, never using it, and then making the feature useless (and potentially wrought with peril) down the road without realizing it!

I think it'd make sense to rename rule_type to policy_type and move to a top-level property of a Policy object, unless someone can propose a scenario where mixing multiple rule_types in one Policy makes sense now.

May 14 '20 14:05 avatarneil

Thanks for that response! That context is very helpful. It seems like we're on the same page re: thinking that rule_type would make more sense getting bumped up a level and renamed something like policy_type - @schnuerle do you think this issue might be a good fit for 1.1.0?

Aug 12 '20 17:08 jrheard

@jrheard We should look at how this would work in practice in the spec. If it's a breaking change it would need to wait for the next release since 1.1 is a minor release (though if we have lots of requests for breaking changes, it's possible to make it a major release 2.0). Maybe we can address it in a non breaking way (documentation/clarification) until then.