Discussion: provider flat-file representation

[thekaveman]

There has been a lot of interest in this over at #58. Here's one starting point to hopefully further the discussion.

The major changes of note:

• the geoJSON route has gone away in favor of the flattened trip_point (including the move of accuracy as proposed on Consider moving accuracy to properties in the route. #51)

• in the spirit of making the spec more friendly and accessible (as with flat files), this changes the date/time formatting to ISO 8601 as originally discussed by @monolyst way back in Some ideas on the specs #8

As part of addressing the desire to have a well-defined object format, .csv files in the models/ directory describe the fields, types, requirements, etc. for each (rather than tables in the README). This is still a little hand-wavy in my opinion, but at least its machine-readable 🤷‍♂️. Not sure if/how this effort can intersect with #46 and its current proposal #53

[ezheidtmann]

Interesting. Just a half-baked thought here, but what if we support the CSV use-case by providing an open-source transform tool that produces CSV based on JSON input?

I like the idea of machine-readable schema, but perhaps we should use an established schema language like JSON Schema. Unless the CSV schema format you use is a standard already?

[migurski]

@ezheidtmann A transform tool could temporarily bridge this gap. I’d like to see it officially supported as a client-side tool on an MDS spec page, maybe found inside this repo? It would require that any MDS Provider API endpoint be fully CORS-compliant.

[hunterowens]

👍 to the idea of a transformation tool rather than a CSV endpoint. @ezheidtmann @migurski.

[ezheidtmann]

Great -- that tool can be developed when a city needs it.

[thekaveman]

It'll still be here for folks to comment on... but I'm closing this PR as we look towards different approaches.