Open richtaylor-ito opened 3 years ago
While GBFS does allow for extensions outside of the spec, extensions should be prefixed with an underscore, which would make it possible to distinguish them from mis-named or mis-used attributes.
Hi @richtaylor-ito, thanks for opening this issue! It seems like this can be handled with additional properties. Adding the following property in the Json Schemas will flag additional properties.
"additionalProperties": false
But this would flag the extensions outside the spec as well... @PierrickP any thoughts on how to solve this problem?
After trying it with an online Json Schema Validator, using "additionalProperties": false
works.
We would need to add it to all properties
levels in order to flag additional fields in all levels of the JSON file.
Here is the modified station_status
file that flags the additional field in Bcycle's feed:
Hello additionalProperties
should work and i think there are a tricks with a regex to only accept underscore prefixed key
"Field names of extensions SHOULD be prefixed with an underscore (_) character." (reference)
The validator should return a WARNING when an additional property does not start with an underscore (_).
additionalProperties
schema to false
to reject additional properties (reference)patternProperties
schema to {"^_": {}}
to accept any property starting with underscore ("_") (reference)JSON Schema example with additionalProperties
and patternProperties
:
When validating a v1.1 station_status.json which uses 'num_bike_available_types' in place of 'vehicles_types_available' (as per the 1.1 schema), the validator doesn't flag this.
An example of this can be seen in Bcycle's feed https://gbfs.bcycle.com/bcycle_lametro/gbfs.json :
{ is_returning: 1, is_renting: 1, is_installed: 1, num_docks_available: 23, num_bikes_available: 8, last_reported: 1635497046, num_bikes_available_types: { electric: 4, smart: 0, classic: 4 }, station_id: "bcycle_lametro_3005" }