Add new fare_action enum options to fare_transactions

[jaygordon]

Added the new actions discussed in the linked issue.

Pull Request

Before submitting a pull request, please read CONTRIBUTING.md.

For spec changes:

• Pull-requests must address an existing issue
• Update relevant documentation.

By contributing to this project, all contributors certify to the Developer Certificate of Origin in CONTRIBUTING.md.

[botanize]

Jay, thank you for this pull-request. I think this looks great, but I'm concerned that the enum values themselves aren't quite self-documenting. If I hadn't read the linked issue I'm not sure what I would have interpreted "Capture" to mean. I see a few options,

1. This is industry standard vocabulary and additional description isn't necessary
2. The enum values could be longer to provide a succinct description, e.g., Button pressed by driver or operator to indicate a boarding or alighting passenger from fare_transactions.media_type.
3. Leave the enum values the same and add descriptions of them to the description property.

[gabriel-korbato]

I like the third option the most. Even if it is industry-standard, some may not be sure what it means. I don't like long enum values because they bloat data files. (At Korbato we use numeric IDs pointing to an enum table.)

[jaygordon]

I prefer the third option too.

[jaygordon]

If we're in agreement I can implement option 3 and add the id and description of each enum value in the description field. I think newlines and tabs would be useful here but I'm not sure how that's parsed. Should I do a single escape (\n) or will a parser require a double escape (\\n)?

[jlstpaul]

Are we still waiting on response to how to add newlines and tabs to the description field? @e-lo @j-meelah @SorenSpicknall do you have any thoughts on that?

[e-lo]

Re Enums...

I like Option 3 and use it in other projects:

3. Leave the enum values the same and add descriptions of them to the description property.

Getting it to render a newline might take trial and error, but I believe that HTML <br> is most likely the winner since it is available in Markdown which is how we are rendering things.

<br>- Value 1<br>- Value 2<br>- Value 3

Another option would be to make an unordered list, which I've done before too.

[e-lo]

And, while I believe that self-documenting within the schema is the right way to go, there is the option to define an RDF type in a separate json-file which could be self-documenting....but gross IMHO.

[e-lo]

Also... submitted frictionlessdata/datapackage#843 for people to add their own thoughts to

[github-actions]

Documentation available at: http://tides-transit.github.io/TIDES/108-add-other-fare_actions