Open josee-sabourin opened 1 year ago
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.