Define frequency of updates for Policy API

[schnuerle]

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

The Policy API does not discuss frequency of updates that are expected, either by the agency serving up the API nor by the provider consuming the API. The only existing language is 'The publishing Agency should establish and communicate to providers how frequently these files should be polled.' in the "Flat Files" section.

With the addition of Rates to Policy in 1.0.0, this was surfaced as an issue and language has been added in the 'Rule Types' table in the 'rate' row. The revised language reads:

Prior to implementation agencies should consult with providers to discuss how the rate rule will be used. Most agencies do this as a matter of course, but it is particularly important to communicate in advance how frequently and in what ways rates might change over time.

A version of this language could be placed in a high level section of Policy, and/or specific update time frames could be defined.

As we look at adding Stops in 1.1.0 #554, this need to define expected update frequency will become more important.

Describe the solution you'd like

Policy needs frequency of updates language at a high level in the Policy spec (not just individual items), and this issue is to discuss and agree upon those terms.

The solution could also be an external guidance document that is referenced and linked to from the repo.

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

Define expected frequency updates for each item in policy.

Additional context

N/A

[Retzoh]

Hi @schnuerle , thanks for this issue. Another way to handle the "update" issue would be for agencies to push policies to providers when they are published, what do you think about it?

This feels like the same problem than getting device events with the Provider API: when polling the events of a time range, there is no guarantee that you aren't missing an event that has not been published yet for some reason (network delay, etc.). The only way to guarantee that you are not missing anything is if the provider actually sends the events as they are available through the Agency API.

[schnuerle]

@Retzoh I see Policy heading this direction eventually. I don't think it's there now, and think it benefits from being a simple one way feed for ease of deployment and management.

Maybe though there could be an optional way for it to integrate with Agency, so that if people are using Agency, it can be pushed that way (eg, there has been an update, go check the Policy API for details)?

The Policy API though can handle current, future, and past events. So you it could currently be used to capture all changes in an ever growing file. Each policy item has a start date/time, end date/time, and a published date/time.

[Retzoh]

I'm not sure I understand what you mean by integrate with Agency, but we can just let this push-idea aside for now.

[schnuerle]

Solved with PR #609.