Can we have DRYer patternProperties keys?

[reitzig]

Say I want to refactor the not-nice(TM)

things:
  - id: abc
    name: "My ABC"
  - id: "def"
    name: "Other letters"

into the nicer(TM) (more idiomatic, anyway?)

things:
  abc: "My ABC"
  def: "Other letters"

I would change the schema of things from array+items to object+patternProperties, moving the pattern from things.items.properties.id to things.patternProperties.

Now, for things.items.properties.id, I could use $ref to point toward a central definition.
For things.patternProperties.$pattern, though, I can't.

That's unfortunate; I have to choose between repeating the same pattern over and over, no doubt introducing inconsistencies at some point, and having those rather useless array layers around.

How about handing two schemas key and value to patternProperties2, with some restrictions on key (admissible values must be a subset of valid JSON keys), as an alternative to the current patternProperties? Might look something like this:

"patternProperties2": {
    "key": {
        "type": "string", // implied / const
        "pattern": "^[a-z]+$"
    },
    value: {
        <snip>
    }
}

Now, we could use $ref inside key, but also enum which I imagine to be useful in some cases.

The current patternProperties would be a special case; it'd translate to something similar to the example above, providing a clear migration path if need be.

[karenetheridge]

If you want to reuse the pattern that you would otherwise use in patternProperties, you can instead switch to propertyNames (which takes a schema) and additionalProperties.

i.e. this:

patternProperties:
  ^[a-z]+$:
    $ref: #/$defs/value_schema
additionalProperties: false

is equivalent to this:

propertyNames:
  pattern: ^[a-z]+$       <-- now you can move this part to a definition
additionalProperties:
  $ref: #/$defs/value_schema

[reitzig]

I had forgotten about propertyNames, thanks!

The interaction with additionalProperties is ... surprising (I routinely use additionalProperties: false to protect against typos) and does not clearly reflect the intent.

This pattern seems weaker than what I propose, too. While it would work in the toy example -- exactly one type of properties -- it does not allow multiple patterns with different values schemas the way patternProperties does, nor does it combine with regular properties well.

That said, for the use case I face today, I think it's just enough. Thanks again!