Variable answer types

[puls]

Fixes #13

@jonahgreenthal

[jonahgreenthal]

(Also: My version would allow for smarter calculation of bonuses_heard. Some weird formats have things like "only tossups in the second half have bonuses".)

[puls]

How about this new version?

[jonahgreenthal]

Getting better, but two last things:

• I'm not clear on why PlayerAnswerCount has a value; I would expect that to be incorporated in its AnswerType
• AnswerType should probably also have a column_header field. For instance, one object might have label : "Power" but column_header : "15s".

[jonahgreenthal]

How are we doing on this?

[puls]

PlayerAnswerCount has a value because of the annotation below: _"Exactly one of value or answertype is required."

As for labels, I feel like we're veering towards prescribing an implementation. I'd say if the column header is "15" then the label should be "15".

[jonahgreenthal]

More precisely, my question about PlayerAnswerCount amounts to "Why do we want the flexibility of allowing either value or answer_type?". It seems like that's just going to make implementation more difficult.

Labels and column headers: My point is sometimes we might want distinct names and short names. Perhaps short_label would be better than column_header; I agree with not wanting to prescribe an implementation, but wanting to call a given question type "Power" in one place and "15" or just "P" in another seems very likely to be wanted.

[puls]

In the simple case (and by "the simple case", I mean "the NAQT case", because really):

{"value":10} vs {"answer_type":{"value":10}} vs {"answer_type":{"$ref":"answer_type_10"}}

is all noise reduction.

I'll add short labels.

[puls]

(That is to say, I'd like to keep the eventual JSON output as human-readable as possible unless it really needs to be obtuse.)

[jonahgreenthal]

Cool; let me know when I should take another look at the diff.

[puls]

Go for it.

[jonahgreenthal]

Hooray!

[jonahgreenthal]

Okay, so that didn't actually merge