canonical-data.json: Compliance with JSON Schema

[rbasso]

Now that #602 was merged, it would be great to have all the canonical-data.json files compliant with the JSON Schema, so that we could automatically check them for errors in the future.

At the moment, we have 74 canonical-data.json files, but only 3 are compliant.

When porting the files, I guess it would be nice to follow a few guidelines to make reviewing easier:

• Distinct commits with the following:
  1. exercise-name: Make canonical-data.json compliant, containing the minimal changes to make the test suite compliant.
  2. exercise-name: Fix canonical-data.json formatting, with the changes needed to make it readable again.
• pull-request's title: exercise-name: Make exercise schema-compliant
• pull-request's body: at least a line containing Related to #625.
• version should start at 1.0.0 and follow the exercise property.

Unless there is already a standard in place that I don't know, I suggest formatting with 2-spaces indentation in the second commit, for consistency, which is already the default when running jq '.' canonical-data.json.

Of course, most of the exercises will demand additional changes to a standard formatting, to make them more compact and readable.

Edit: Just to be clear, this issue is not about style in designing the test suite. Changes that go beyond fixing the test suite to be compliant and fix it to be consistently formatted after that should be avoided here!

---

canonical-data.json compliance

• acronym #626
• allergies #628
• all-your-base #630
• alphametics #675
• anagram #631
• atbash-cipher #632
• beer-song #661 / #694
• binary #644
• binary-search #676
• bob #636
• book-store #635
• bowling #677
• bracket-push #680
• change #641
• circular-buffer #681
• clock #669
• connect #670
• crypto-square #652
• custom-set #672
• diamond #612
• difference-of-squares #653
• dominoes #682
• etl #654
• flatten-array #683
• food-chain #684
• forth #688
• gigasecond #685
• grains #642
• grep #712
• hamming #627
• hello-world #629
  • Need bump to 1.0.0
• isogram #686
• largest-series-product #689
• leap #633
• list-ops #690
• luhn #643
• markdown #691
• meetup #663
• minesweeper #664
• nth-prime #665
• nucleotide-count #666
• ocr-numbers #667
• pangram #687
• pascals-triangle #668
• perfect-numbers #611
• phone-number #678
• pig-latin #646
• pov #704
• prime-factors #695
• queen-attack #655
• rail-fence-cipher #696
• raindrops #637
• react #697
• rectangles #698
• rna-transcription #638
• robot-simulator #656
• roman-numerals #711
• rotational-cipher #701
• run-length-encoding #702
• say #647
• scrabble-score #639
• secret-handshake #657
• sieve #649
• space-age #703
• sublist #705
• sum-of-multiples #650
• tournament #717
• transpose #706
• triangle #651
• trinary #645
• two-bucket #713
• variable-length-quantity #708
• word-count #634
• wordy #648

[petertseng]

The final goal here is that we will be able to run every canonical-data.json through a schema check, right?

Then can I propose we do not wait until all canonical-data.json are compliant before starting to do that?

Let's start check them all ASAP, and allow those listed in a file named allowed-schema-failures (or something) to fail.

Because we wouldn't want a file that was compliant to fall out of compliance while this project is underway.

The goal of course will be to drive the number of lines in the file down to zero.

[rbasso]

If anyone wants to port and exercise to the new schema, I is a good idea to say here, so that we don't make useless duplicated work.

[kotp]

Working on Hamming

[rbasso]

Working on: hello-world, all-your-base

[catb0t]

I'll tackle leap and word-count.

[rbasso]

Working on: anagram, atbash-cipher and bob.

[rpottsoh]

I've got book-store.

[rbasso]

Working on raindrops, rna-transcription and scrabble-score.

[rbasso]

Working on change, grains and luhn.

[rbasso]

Working on binary and trinary, deprecated exercises.

[rbasso]

Working on pig-latin, say and wordy.

[rbasso]

Working on sieve, sum-of-multiples and triangle

[rbasso]

Working on crypto-square, difference-of-squares and etl.

[rbasso]

Working on queen-attack, robot-simulator and secret-handshake.

[rbasso]

Working on meetup, minesweeper and nth-prime.

[tejasbubane]

Working on adding schema validation to travis.

[kotp]

[rbasso]

Working on nucleotide-count, ocr-numbers and pascals-triangle.

[rbasso]

Working on clock, comment and custom-set.

[rbasso]

Working on alphametics, binary-search and bowling.

[rbasso]

Working on bracket-push, circular-buffer, dominoes, flatten-array and food-chain.

[tejasbubane]

@rbasso I am a little confused with the `property` field. Since it is required in all test cases, is that supposed to be the function/method name in the implementation? The [description here](https://github.com/exercism/x-common/blob/master/canonical-schema.json#L115) is not very useful.

[rbasso]

The description here is not very useful.

Sorry for the description!

The property is a string that uniquely identifies a test type.

In test-suite-generation terms, it is a reference to an external test-logic, a way to turn the test data in a real test. Ops, I guess I made the explanation worse. 😁

I am a little confused with the property field. Since it is required in all test cases, is that supposed to be the function/method name in the implementation?

In most of the situations, yes! It can be the name of a function! Just keep in mind that if the tests use the same function (test logic), they need to have the same property.

[tejasbubane]

[rbasso]

Working on forth, grep and largest-series-product. We are almost there...

Edit: grep needs a complete redesign to match the new schema, because it encodes files in the JSON. Not touching it for now.

[rbasso]

Working on list-ops, markdown and pov.

Edit: pov also needs a redesign to match the new schema, because it has objects shared by test cases. Not touching it for now.

[tejasbubane]

grep needs a complete redesign to match the new schema, because it encodes files in the JSON. Not touching it for now.

@rbasso Does this mean we need a way to ignore some exercises from the CI? (in #658)

[rbasso]

Don't worry about that for now, @tejasbubane. I already have an idea about how to sidestep the grep problem, but I'm waiting to see if I find more incompatible exercises to so that we can rewrite them together in a more consistent way.

[rbasso]

Working on prime-factor, rail-fence-cipher, react and rectangles.

[rbasso]

Working on rotational-cipher, run-length-encoding and space-age.

[petertseng]

I guess I have to do pov.

[kotp]

Make sure to see @rbasso concerns with pov and grep, among others... referenced #699

I see you are already aware, @petertseng

[rbasso]

Thanks, @petertseng ! pov is the hardest by far...

[rbasso]

Working on sublist and transpose.

[rbasso]

Working on two-bucket and variable-length-quantity.

Edit: two-bucket needs descriptions and a good property name. Not touching it today.

[rbasso]

People, we are at full compliance with the JSON schema at the moment.

[kotp]

Now we will party like it's 18 years ago!

[rbasso]

I'm glad to say that, after something around 150 commits (+75 merges), we are almost done. We just need some eyes in #658 to review enforcing it in Travis-CI, then this chapter of the standardization saga will be over. 🎉 🎊

I know that I'm guilty of rushing the conversion to this new schema a little, but we did all possible to avoid changes in the test contents, so I just hope no one will be mad with me. 😁

In the few cases where meaningful test-data changes where really needed, we bumped the version to 1.1.0, so it should be easy to identify those exercises.

I'm sorry for adding some completely unhelpful description to tests that where missing them. Some property names I added are also regrettably horrible.

That said, the changes are not forever, and I expect the errors and bad decisions will be fixed someday.

Thanks to everybody who joined this task force! 👍

Now, if you excuse me, I'll try a JSON-detox for a while. 😷