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
Certain feeds with additional non-spec fields are being checked as valid.
Example: Citibike includes fields in station_information.json like electric_bike_surcharge_waiver and external_id, but the validation report says no errors.
I opened this issue on both this repo and the validator. My initial instinct for a solution would be to add an additionalProperties: false to the schemas, but would like to make sure before opening a PR.
The text was updated successfully, but these errors were encountered:
The specification has always explicitly allowed for non-spec fields (extensions) so it seems like these feeds should be valid. Initially these fields were supposed to be prefixed with the feed vendor's name. If you look at the Citibike feed you'll see: "eightd_has_available_keys": false,
Eight D was the name of the system vendor when that feed was implemented.
Some time ago, I think in v2.2, we decided that we would use an underscore prefix in place of the vendor name for extensions because that's how OpenAPI was handling this issue at the time. They've since changed to a[ different prefix ].(https://swagger.io/specification/#specification-extensions)
Part of the intention of the prefix is to make it possible to identify incorrectly named fields, for example if a feed contained cargo_capacity when is should be cargo_volume_capacity. Using the prefix would allow a validator to overlook any custom extensions while still being able to flag the incorrectly named cargo_capacity field.
Certain feeds with additional non-spec fields are being checked as valid.
Example: Citibike includes fields in
station_information.json
likeelectric_bike_surcharge_waiver
andexternal_id
, but the validation report says no errors.I opened this issue on both this repo and the validator. My initial instinct for a solution would be to add an
additionalProperties: false
to the schemas, but would like to make sure before opening a PR.The text was updated successfully, but these errors were encountered: