Specify a data format for process clients

[wilbertom]

We have settled on using JSON objects. Now we have to choose the format in which the data is coming in. Here are some proposals. Edit this page to contain a single complete format.

[bepetersn]

I am definitely in favor of the second one, sticking closely to the format the sheriff's website gives us. Norbert also recommended using the Inmate Details class as our uniform data format, which is close to the same thing. For instance, there's a "charges" instead of our new "citation" and "charge description" fields.

Your justification for the second format is a decent one, and is one way to look at it. If we base it on our models, then change them later, we'll have problems. Here's another way. This is a really old document that is in our wiki:

https://github.com/sc3/cookcountyjail/wiki/General-Statistics:-What-we-know-and-what-we-don't

I renamed it to what it is now, to give it a slightly more meaningful name, but it was added to github before I started working on the project. And here is what it is talking about: the information that we can learn about inmates from the data available on the sheriff's website. That is, after all, the point of this project. And that's why we should use the second data format to feed to the v2 API. Because it won't change, yes, but more crucially, because it basically represents the data we're interested in. No more and no less.

[nwinklareth]

I perfer the 2nd one, the flat model. The less processing, the less shaping of the data we do up front, the more options we provide to people who use this data.

[wilbertom]

I'm deleting this documentation and replacing it with Norbert's document along with documentation for the new architecture.