Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
josee-sabourin opened this issue Mar 22, 2023 · 1 comment
Open

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

josee-sabourin opened this issue Mar 22, 2023 · 1 comment

Comments

@josee-sabourin
Copy link
Contributor

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants