search

google / transit

https://gtfs.org/
Apache License 2.0
600 stars 182 forks source link

Update GTFS to RFC 2119 #273

Closed scmcca closed 3 years ago

scmcca commented 3 years ago

Hi everyone. We (MobilityData) want to get some thoughts from the community on updating GTFS to RFC 2119.

In short, RFC 2119 is a standard of keywords to indicate requirement levels (i.e., "MUST", "SHOULD"). It is used by similar data standards such as GBFS and IMDF to draw clear distinctions around what is required and what is recommended in the specification. These clear distinctions are not made in GTFS, leaving room for interpretation, ambiguity, and make the spec harder to grasp for both newcomers and experienced stakeholders when it comes to producing, consuming, and creating products (i.e., validators) around GTFS.

In terms of updating GTFS documentation to RFC 2119, little change would be needed in the majority of cases. In some cases, parts of the spec may need minor edits to be RFC 2119 friendly, without changing the content (such as replacing "can" with the RFC "MAY"). The goal is to have a data standard that is legible and clear.

Pending feedback here, we would begin this work with GTFS Schedule, followed by GTFS Realtime. Looking forward to any thoughts on this. Thanks!

skinkie commented 3 years ago

What we as producer observe is that some more critical consuming clients (organisations that pay the bills) ask for certain features to be present "because it is in the standard". For MUST this is pretty clear, but the distinction between SHOULD, MAY, optional, best-practice is not. I think this must also be "commercially" clear that implementing a certain feature because all fields are filled in is not better than some fields ignored.

e-lo commented 3 years ago

We are thinking about this at Cal-ITP and believe that being able to point to a clearly and consistently articulated list of SHOULD statements which are articulated in the spec itself would be easier to articulate in contract language as well as enforce than the current state of the spec + various best practices.