extraneous elements are permitted due to use of allOf

[catkins-miso]

As identified in #158, examples in the spec can have elements that are not specified, and the linter doesn't catch them. This is because we cannot use additionalProperties: false to constrain the message schema as discussed here #158 (comment)

Unfortunately, the idea of using YAML merge, e.g., <<: *merge_token to hack our way out of this situation is not practicable, since most of the allOf uses also employ $ref inclusions, and YAML merge only supports same-file definitions.

It's important to note that the impact here isn't just the examples in the spec, but also the allowable messages in a TROLIE-conformant information exchange. Technically, the spec currently allows any number of spurious properties to be included in a message. Tools like 42crunch explicitly warn about this, but we've necessarily ignored them for these allOf properties.

AFAICT, that leaves us with the options of:

• moving to OpenAPI 3.1.0 for access to unevaluatedProperties: false,
• or repeating several schema definitions where they are reused,
• or eliminating the entire split/combine step and editing on giant openapi.yaml.

I cannot really evaluate the cost of moving to OpenAPI 3.1.0 without feedback from current and potential implementors, but we originally wanted to provide the broadest support possible for the API client generators, and unfortunately some popular tools do not support it.

[catkins-miso]

FWIW, the impetus for creating this issue was finding another instance of an extraneous element

spec/docs/example-narratives/examples/forecast-limits-detailed.json

Line 49 in b83beae

"limiting-segment": "segmentX",

[catkins-miso]

The yaml merge in the recdocly tooling supports multiple refs, i.e., <<: [*ref1, ref2]. Using this allowed us to consolidate many files into period-limit.yaml and removing all uses of allOf.