Problem-specifications: recitation exercises: Standardise canonical data interface.

[Insti]

There are 4 exercises that involve reciting songs/poems.
beer-song, food-chain, house and twelve-days.

Currently these are tested using differing combinations of verse and verses.

There has been some discussion in recent PRs (#973, #954) about standardising the interfaces specified in the canonical data. With the current thinking that:

---

The property we are testing should be recite
There should be 2 other properties present: startVerse and endVerse
Both startVerse and endVerse must be specified in the canonical-data.json file, even if only one verse is desired.

---

By being explicit about startVerse and endVerse in the canonical data we can maintain a single consistent unambiguous interface for all tests.

There is no requirement for a language track to implement a one-to-one mapping from canonical data properties to test inputs.

If a track wants to implement tests for a function that takes differing numbers of arguments or call different methods if there is only one argument, or use a name other than recite they can still do this by applying minor transformations to the provided canonical properties.

To do:

Standardise the canonical data for the following exercises:

• [x] beer-song (Complete #984)
  
  
  
  • description says to "produce the lyrics"
  
  
  • canonical-data.json checks verse and verses
  
  
• [x] house (Complete #985)
  
  
  
  • description says to "output the nursery rhyme"
  
  
  • canonical-data.json checks verse and verses
  
  
• [x] food-chain (Complete #973)
  
  
  
  • description says to "generate the lyrics"
  
  
  • canonical-data.json checks verse sometimes with one argument, sometimes with two
  
  
• [x] twelve-days (Complete #954)
  
  
  
  • description says to "Output the lyrics"
  
  
  • canonical-data.json does not exist yet.
  
  

Additional recitation exercises:

• [x] proverb (Complete #994)
  
  
  
  • description says to "output the full text"
  
  
  • canonical-data.json property: "recite"
  
  

Edit: Transform keys to lowerCamelCase

[robkeim]

@Insti I can take this one

[Insti]

Great @robkeim.

food-chain and twelve-days are already underway, so just beer-song and house to do, make sure to make a separate PR for each.

Also be aware that there might be objections or alternative suggestions appearing over the next few days, so you'll need to keep an eye on this thread and possibly update the PRs accordingly.

[robkeim]

Sounds good @Insti. I've gone ahead and send two PRs:

• beer-song #984
• house #985

[Insti]

Are keys with spaces in them a good idea?
Many other exercises use camelCaseKeys

house and food-chain seem to be the only ones that currently have spaces in the keys.

[NobbZ]

Personally I do not care at all, if they are used as name for a properties arguments.

I have to extract and rename them anyway, since in Erlang variables have to start with a capital letter.

But in general I do think, that restricting to camel or snakecase without whitespace is the way to prefer, since then it can uniformely accessed in dot-notation across many languages.

[robkeim]

@Insti, I'm personally not a fan of spaces in the keys, I only changed to go that direction after seeing that house had them already and that your description had them as well.

camelCaseKeys sound good to me as that's standard for json notation.

[rpottsoh]

Personally I prefer that there not be spaces. I end up removing them anyway, Delphi cannot have spaces in variables/methods etc etc.

camelCaseKeys makes for less work for me later.....

[Insti]

I think the intention is that they should be lowerCamelCase, but there is something wrong with the validation process. arbitrary keys appear to not be validated.

https://github.com/exercism/problem-specifications/blob/master/canonical-schema.json#L20-L24

, " Additionally, this schema strictly enforces letters, in "
, " lowerCamelCase, for naming the 'property' being tested. We "
, " expect this regularity will allow an easier automatic "
, " generation of function's names in test generators, "
, " slightly reducing the amount of manually generated code. "

[Insti]

I've updated the key names in the OP to match this.

[robkeim]

@Insti I've gone ahead and update both of my PRs to reflect this change.

[ErikSchierboom]

@Insti I've also updated my PR.

[Insti]

All the to do's are done! :tada:
Thanks everyone.