Problem-specifications: json schema validation: enforce lowerCamelCase keys

[Insti]

There is a json schema definition for the canoncial-data.json file.
https://github.com/exercism/problem-specifications/blob/master/canonical-schema.json

However this still allows for arbitrary keys containing spaces.
These keys are often used for specifying test input arguments.

https://github.com/exercism/problem-specifications/blob/637cca615dbbb52d61d0a7a74d71c09360bdebf4/exercises/food-chain/canonical-data.json#L21

Task

Update the https://github.com/exercism/problem-specifications/blob/master/canonical-schema.json to require all keys to be lowerCamelCase

[Insti]

Is this a good idea?

• I'm personally fine with keys that contain spaces.
• It is only food-chain and house that currently contain keys that contain spaces. (there are pull requests open that may change this: #985, #973 )
• No-one has (yet) raised any issues with parsing the json for these exercises.
• For some languages being able to assume that json keys will not contain spaces will make parsing easier.

[NobbZ]

I'd not say that parsing is easier or harder, but usage.

In some languages keys are transformed in a way that we can use the keys name as an accessor of a struct/object/record like thing (eg. case.startVerse). If though they contain spaces they need to be often treated differently by using array like accessors (eg case["start verse"]).

I'm not affected by that in erlang anyway. But I have to match on the keys using atoms, and usually atoms in erlang are alphanumerics + underscore, beginning with lowercase alpha. I can though construct atoms that contain all kind of characters (in modern erlang even unicode characters) as long as they do not exceed 256 (or was it 255) bytes in their UTF8 representation. But I have to quote them then using single-quote character: (startVerse vs. 'start verse'). Even though quoted atoms are possible, a rule of thumb is to avoid them, since the quoting often leads to problems in IDEs and when talking with people from the outside world. They often consider them plain strings which is wrong.

So even here I'd prefer a way that avoids quoting the key.

[ErikSchierboom]

So even here I'd prefer a way that avoids quoting the key.

Agreed. I'm also in favor of enforcing lowerCamelCase keys.

[rbasso]

Nice change, @Insti. We didn't enforced that in the schema in #602 at the time because my json-schema-fu [is|was] too weak.