Specify IDs characters range restrictions #545
Conversation
This PR clarify and restrict the characters allowed in IDs. See MobilityData#541 for additional details. Those edits have multiple goals: - Clarify the current specification that is too vague - Ensure interoperability, it MUST be possible to store and compare IDs simply - Ensure that IDs are easy to manipulate by humans, because even if the format is design for machines, IDs are often used by humans to debug, so they SHOULD be easy to read and write, regardless of the keyboard layout or system used. With that specification, all IDs present in `system.cvs` should stay compliant (excepts those using spaces `0x20`, who are already not compliant with the current specification). Also, all other shared mobility systems that I have seen (GBFS or not) are compatible with both restrictions (again, except for spaces in a case that looks like an error). Does anyone think that IDs should be restricted further, such as `A-Za-z0-9_-:`? (And consider that existing system that are using `.@/` are compliant because "SHOULD" means "that there may exist valid reasons in particular circumstances to ignore a particular item", and at least "legacy" may fit into that. Fix MobilityData#541
|
tagging others for visibility: @cmonagle @viestat @ArashMansouri @futuretap @AntoineAugusti @ezmckinn @fbouchPBSC @Carl-NM @bdferris-v2 @kulovan |
|
+1 looks good |
|
+1 as well |
richfab
added
proposal:breaking
gbfs.md
v3.0-RC2
|
(+1) Tom is my colleague, and we work on it together |
|
+1 From Transit |
|
+1 from Entur |
gbfs.md
Outdated
| @@ -202,7 +202,8 @@ Example: The `rental_methods` field contains values `creditcard`, `paypass`, etc | |||
| * ID - Should be represented as a string that identifies that particular entity. An ID: | |||
| * MUST be unique within like fields (for example, `station_id` MUST be unique among stations) | |||
| * Does not have to be globally unique, unless otherwise specified | |||
| * MUST NOT contain spaces | |||
| * MUST be in the ASCII printable caracter range, space excluded (0x21 to 0x7E) https://en.wikipedia.org/wiki/ASCII#Printable_characters | |||
|
+1 |
caracter => character (thanks @futuretap)
|
(to conform with https://github.com/MobilityData/gbfs/blob/master/governance.md) I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on Oct 12. |
|
@futuretap @AntoineAugusti @cmonagle @testower @Cj-Malone Thank you for the +1. I'm told that to as official as possible, votes should be done after the call to vote. I'll be grateful if you could confirm your vote before 11:59PM UTC on Oct 12 and include the organization for which you are voting in your comment. |
|
+1, transport.data.gouv.fr |
|
+1 from Where To? / FutureTap |
|
+1 from Lyft |
|
Voting on this PR closes in 2 calendar days. Please vote for or against the proposal, and include the organization for which you are voting in your comment. Please note if you can commit to implementing the proposal. |
|
+1 from Entur |
|
+1 from Google |
|
This vote has now closed, and it passes! Votes in favor: This change will be added to v3.0-RC2, which will be released in the coming weeks. |
richfab
changed the title
richfab
changed the title
This PR clarify and restrict the characters allowed in IDs. See #541 for additional details.
Those edits have multiple goals:
With that specification, all IDs present in
system.cvsshould stay compliant (excepts those using spaces0x20, who are already not compliant with the current specification).Also, all others shared mobility systems that I have seen (GBFS or not) are compatible with both restrictions.
Does anyone think that IDs should be restricted further, such as
A-Za-z0-9_-:? (And consider that existing system that are using.@/are compliant because "SHOULD" means "that there may exist valid reasons in particular circumstances to ignore a particular item", and at least "legacy" may fit into that.Fix #541
Is this a breaking change?
Which files are affected by this change?
Most of them