V3.0-RC Schemas

[josee-sabourin]

New directory of schemas for v3.0-RC.

Specifically looking for input on system_information.license_url and license _id.
Used anyOf similarly to the way it's been used in vehicle_status with lat, lon and station_id in previous versions. Is that the best way of representing this?

[isabelle-dr]

A few meta comments:

• it's a little difficult to review everything in one commit, in the next one I think we could have one commit per PR merged as part of the release.
• the structure of gbfs.json seems different from the previous version, is this on purpose? I used this tool to compare the gbfs.json files in the v2.3 and v3.0-RC folders. Some fields aren't at the same nesting level.

I will update this list as I am reviewing this PR!

• Require license_url, add attribution fields gbfs#182 - Require license_url, add attribution fields
• Required rotation of deeplinks vehicle identifier gbfs#247 - Required rotation of deeplinks vehicle identifier
• Change to OSM opening_hours format for times and dates gbfs#328 - Change to OSM Opening Hours format for times and dates
• Add Phone Number to Field Types gbfs#351 - Add Phone Number to Field Types
• Remove string field type from price field gbfs#352 - Remove string field type from price field
• Semantic Changes: Bike becomes Vehicle gbfs#354 - Semantic Changes: Bike becomes Vehicle
• Extending vehicle_types.json gbfs#370 - Extending vehicle_types.json
• File requirements and Clarifying changes gbfs#384 - File requirements and Clarifying changes
• Changes to data structures gbfs#407 - Changes to data structures
• Feed_contact_email required gbfs#454 - Feed_contact_email required
• Reservation Price gbfs#457 - Reservation price
• Internationalization of free-form text gbfs#460 - Internationalization of free-form text
• New Endpoint - manifest.json gbfs#462 - New endpoint - manifest.json
• Add description to vehicle_types gbfs#470 - Add description to vehicle_types
• Require lowercase enums gbfs#474 - Require lowercase enums
• Geofencing refactor gbfs#481 - Geofencing refactor

[josee-sabourin]

Noted on using multiple commits next time, that was my bad!

As for gbfs.json, yes this is correct. The PR for internationalization removes the need to duplicate your feed per language, so that nesting level is gone.

[isabelle-dr]

Sounds good!
I've created a fake PR to be able to compare v2.3 and v3 using GitHub's diff interface.

[isabelle-dr]

Here my understanding of the spec is that license_id and license_URL can both be left blank and that license_URL must not be provided if license_id is present.

I've tested:

• license_id and license_URL are present -> invalid ✅
• onlylicense_id is present -> valid ✅
• onlylicense_url is present -> valid ✅
• license_id and license_URL are not present- > invalid ❌ (we want this to be valid)

[isabelle-dr]

It looks like we need something else than anyOf to validate this 🤔

[josee-sabourin]

I think perhaps oneOf might be the proper solution and not required

[josee-sabourin]

Asking for help from @testower or @AntoineAugusti (or anyone else!), oneOf doesn't seem to solve the problem, since it still requires one of the options, I can't seem to determine how to represent one of or none.

Any ideas?

[AntoineAugusti]

From https://stackoverflow.com/a/38799750/2645887

Maybe

"dependencies": {
  "license_url": { "not": { "required": ["license_id"] } },
  "license_id": { "not": { "required": ["license_url"] } }
},

[josee-sabourin]

This seems to work! Merci @AntoineAugusti!! @isabelle-dr do you want to confirm as well or should I make the change?

[isabelle-dr]

@josee-sabourin I've just pushed a commit that fixes this problem, please confirm!
It does the following:

• license_id and license_URL are present -> invalid
• onlylicense_id is present -> valid
• onlylicense_url is present -> valid
• license_id and license_URL are not present- > invalid

[josee-sabourin]

confirmed!

[isabelle-dr]

Did you look into using a Regex expression to validate the opening hour?

[josee-sabourin]

I have, but I have not been able to find one that works for all possibilities.

[isabelle-dr]

Okay, I am finished with this review! I've added two comments in-line.
Besides this, three meta comments:

1. We should open an issue on the GBFS validator to ass a custom rule to validate the new conditional requirement added here for default_reserve_time in vehicle_types.json:

REQUIRED if reservation_price_per_min or reservation_price_flat_rate are defined.

2. Do we want operators to tag their version as 3.0-RC, or 3.0? The JSON Schema is using 3.0-RC and the examples in the spec is using 3.0. It might be more clear to use the same in both places.

3. We should remove Extending vehicle_types.json gbfs#370 from the list of PRs in v3.0-RC release, it was part of the V2.3

[josee-sabourin]

Some answers for you:

1. Will do!
2. For now we want operators to use v3.0-RC, I will update the examples on the spec
3. See comment here showing that 370 is actually a change for both 2.3 and 3.0

[isabelle-dr]

Ready to go!
Awesome work @josee-sabourin