You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a field is described as Conditionally Required in the spec, three cases exist:
A field or file is required under a certain condition, optional otherwise. It is the case for the calendar.txt, calendar_dates.txt, and levels.txt files, for the fields stops.stop_name, stops.stop_lat, stops.stop_lon, stops.zone_id and for many other fields.
A field or file is required under a certain condition, forbidden otherwise. it is the case for fare_transfer_rules.duration_limit_type, translations.record_id, and translations.field_value.
A field or file is required under a certain condition, forbidden under another condition, and optional otherwise. It is the case for stops.parent_station.
Problem
In the Fares v2 base implementation PR, a new presence condition was added to the spec: Conditionally Forbidden, and was applied to fare_transfer_rules.transfer_count. This field has the behavior described in category 2 above: required under a certain condition, forbidden otherwise.
We believe this field was initially designed as: forbidden under a certain condition, optional otherwise, and then changed when modifications were made to the PR.
This adds unnecessary complexity to the spec, this condition should only be used if a field is either forbidden or optional.
Solution
Remove the Conditionally Forbidden presence condition from the spec and describe fare_transfer_rules.transfer_count as Conditionally Required.
I'm happy to open a PR to do this fix if there is agreement from the community.
The text was updated successfully, but these errors were encountered:
👋 I'm going through our issue backlog to see if there's anything relevant to roll into the scope for #376. It looks like #376 may be a good opportunity to remove Conditionally Forbidden as well since there was 4 thumbs up in favor of this issue and no dissent.
This issue has been automatically marked as stale because it has not had recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.
Context
When a field is described as Conditionally Required in the spec, three cases exist:
A field or file is required under a certain condition, optional otherwise. It is the case for the
calendar.txt
,calendar_dates.txt
, andlevels.txt
files, for the fieldsstops.stop_name
,stops.stop_lat
,stops.stop_lon
,stops.zone_id
and for many other fields.A field or file is required under a certain condition, forbidden otherwise. it is the case for
fare_transfer_rules.duration_limit_type
,translations.record_id
, andtranslations.field_value
.A field or file is required under a certain condition, forbidden under another condition, and optional otherwise. It is the case for
stops.parent_station
.Problem
In the Fares v2 base implementation PR, a new presence condition was added to the spec: Conditionally Forbidden, and was applied to
fare_transfer_rules.transfer_count
. This field has the behavior described in category 2 above: required under a certain condition, forbidden otherwise.We believe this field was initially designed as: forbidden under a certain condition, optional otherwise, and then changed when modifications were made to the PR.
This adds unnecessary complexity to the spec, this condition should only be used if a field is either forbidden or optional.
Solution
Remove the Conditionally Forbidden presence condition from the spec and describe
fare_transfer_rules.transfer_count
as Conditionally Required.I'm happy to open a PR to do this fix if there is agreement from the community.
The text was updated successfully, but these errors were encountered: