$recursiveRef part 3 of 3: Update meta-schemas

[handrews]

hyper-schema is a lot simpler now.

[gregsdennis]

Although not part of this PR, specifically, can definitions just redirect to $defs rather than repeating the subschema? Or is there some deeper purpose to having it explicit?

Maybe something like

"definitions": {
  "$recursiveRef": "#/properties/$defs",
  "$comment": "look at how well keywords fit right next to $refs!"
}

[handrews]

I kind of feel like best practices is for refs to target #/$defs/..., not #/properties/..., and it seems overkill to factor this out.

[gregsdennis]

That's fair, but it also feels redundant to have a definition that is truly supposed to be the same thing in here twice. Maybe move the whole thing to a definition and have both properties reference it

[handrews]

I like the explicitness more than I am concerned about a 3-line redundancy here.

[gregsdennis]

I rather like this being explicitly defined as a schema dependency vs a property dependency. Why are you changing back to just dependencies?

[handrews]

That was unintentional and I have no idea, thanks for catching. I blame coming back to this after three months and probably my tree was in a weird state.

[gregsdennis]

This change doesn't fit the wording of the propertyNames keyword.

The value of "propertyNames" MUST be a valid JSON Schema.

If the instance is an object, this keyword validates if every property name in
the instance validates against the provided schema.
Note the property name that the schema is testing will always be a string.

Omitting this keyword has the same behavior as an empty schema.

[gregsdennis]

I wonder if there's a way that we can write a schema that validates schemas that validate strings. That would be perfect here.

{
  "allOf": [
    { "$recursiveRef": "#" },
    {
      "type": "object",
      "properties": {
        "type": {"const":"string"}
      },
      "required": [ "type" ]
    }
  ]
}

Concise? No. Explicit? Yes. Necessary? ¯\_(ツ)_/¯

[handrews]

This change was also unintentional. Generally, we make the meta-schema more permissive rather than trying to lock it down. We've gone over similar changes before and always decided not to do them. It's totally valid to write propertyNames without type (JSON is not capable of serializing anything else, so its utility is debatable), or even with the wrong type (although I have no idea why, or what useful thing it could do). There's a similar restriction with hrefSchema that it probably should have type: object but we don't enforce that either.

[handrews]

OK, apparently I grabbed a really old meta-schema for this change originally somehow. I've fixed it so it no longer reverts the last few other changes :-/ I left the change trimming # from the end of $id and from $ref and $recursiveRef that are not only #, because I think that had to do with URI normalization conventions. Although anyone is free to argue that point as I don't actually remember the rationale.