MobilityData / gbfs-json-schema

JSON Schema for GBFS feeds, managed by MobilityData. The versions are organized by folders. CC BY 4.0
Apache License 2.0
23 stars 24 forks source link

Validator allows for non-GBFS fields to be valid #80

Open josee-sabourin opened 1 year ago

josee-sabourin commented 1 year ago

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.

mplsmitch commented 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.