Allow numeric keys to be classified as errors

[tschaible]

User story.
As a user who needs OpenAPI YAML to be valid for other tools, I would like the incorrect usage of numeric keys to be identified as an error.

Is your feature request related to a problem?
In #955 it seems like the misuse of numeric keys in YAML was changed from an error to a warning.

I actually want it as an error, since numeric keys in YAML break other tools in my tool-chain.

Since the violation comes from parser it seems like I can't change the severity. I would like control of this, so I can classify it as an error.

Describe the solution you'd like
Either of the two options below would be great

extends:
rules:
  parser:
    key-string-scalar: error

or

extends:
rules:
  parser-key-string-scalar: error

[P0lip]

@tschaible
Hey! We're open for implementing it.
I cannot promise any date yet, but this is certainly worth considering.
I'd be more leaning towards implementing an extra property in the ruleset called parserOptions or similar.
What do you think?

[tschaible]

thanks @P0lip

parserOptions would definitely meet my needs as long as it lets me adjust the severity of the individual parser violations

[nulltoken]

@P0lip While we're at it. Couldn't we turn it back to raising an error (and leverage that parserOptions to tune it down)?

FWIW, OAI/OpenAPI-Specification#2171 has been closed as "not an issue".

[philsturgeon]

I think the decision made in #955 was the wrong one. It is invalid OpenAPI, and we consistently treat invalid OpenAPI as an error, not a warning.

The attempts to change OpenAPI itself (as @nulltoken linked to there OAI/OpenAPI-Specification#2171) were rejected, so we're now doing the wrong thing. If that had gone through, we'd still be doing the wrong thing, but it would be only wrong for a short time.

Some tools might not give errors for numeric keys here, but one tool being blasé and ignoring the spec makes problems for anyone who uses that tool, then takes the spec to another tool which does care about the spec.

I'd rather we treated this like an error, and if folks don't like it they should be able to turn the rule off.