Many `test/problems/*/problem.yaml`s break the specification

[thorehusfeldt]

Background

In a problem.yaml, the key name specified as

Key	Type	Default	Comments
name	String or map of strings		Required. If a string this is the name of the problem in English. If a map the keys are language codes and the values are the name of the problem in that language. It is an error for a language to be missing if there exists a problem statement for that language.

should look like this:

name: Muffin

or this:

name:
  'en': Muffin
  'nl' : Stroopwafel
  'da': Wienerbrød

but not like this:

name:

or be missing.

The contents of a problem metadata configuration file problem.yaml are specified at

• https://www.kattis.com/problem-package-format/spec/problem_package_format#problem-metadata

My best bet at expressing the specification in CUE is at

• https://github.com/thorehusfeldt/BAPCtools/blob/spec/support/schemas/problem.cue

Observation

Various .yaml files in BAPCtools (typically intest/problems/*/problem.yaml, break a narrow reading of the the specification, typically by specifying key: null or missing the required name field.

(In fact, both of the yaml files provided as examples in the problem package specification at https://www.kattis.com/problem-package-format/examples/problem_yaml break the specification as well, but that’s not a BAPCtools issue.)

What to do

1. Agree on a valid CUE specification of the problem metadata file, possibly by taking the above draft as a starting point. This requires discussion of what constructions like name: null should even mean, and what kind of legacy traditions exist.
2. run cue vet ../../test/problems/fltcmp/problem.yaml *.cue -d "#problem_settings" etc. on all the problem.yaml files in BAPC-tools; edit as needed.
3. consider doing something similar for contest-level yaml (problems.yaml, contest.yaml), this task includes specifying them in CUE
4. automatically run cue vet to on problem.yaml files, as well as generators.yaml against their respective schemas to make sure that files on the master branch agree with their schemas (and the documentation).