Option to exclude defined/evaluated properties from propertyNames

[strega-nil]

I'm writing a schema for an internal config file, and I want to be able to 1) add comments (i.e., fields whose name starts with a #), 2) add a $schema, 3) use the properties that are necessary for configuration. How I thought I would do this is with:

{
  "type": "object",

  "propertyNames": {
    "pattern": "^[#\\$]",
    "#": "note, starts with a # or a $"
  },

  "required": [ "toolset", "..." ],

  "properties": {
    "toolset": { "...": "..." },
    "...": "..."
  }
}

However, both propertyNames and properties are checked, and so if I have toolset, it doesn't match against ^[#\\$]. I'm wondering if this is intentional, and if it is, what's a good workaround?

Thanks!

[gregsdennis]

1. What implementation are you using?
2. What are you trying to achieve?

propertyNames and properties are completely distinct checks. properties checks the value of each property against an associated schema (e.g. ensure that the value for toolset is of the correct shape). propertyNames checks the name of the property against the associated schema.

Additionally, both of these are checked against the instance, not internally checked in the schema.

So it seems that any instance validated by this schema should fail.

1. toolset is required, but
2. toolset doesn't match the regex pattern for property naming.

It seems that the implementation you're using may be omitting the properties explicitly defined by properties from the propertyNames check, although the spec doesn't say that it should.

6.5.8. propertyNames

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.

If that's the case, you might try another validator just to test.

[strega-nil]

I'm using the VSCode validator, and the result that I am getting is the result that the spec says that I should -- however, I'm questioning the spec, since it doesn't seem useful to check the propertyNames field against fields that already exist in properties. I'm wondering if that was intentional, and if so, the reasoning behind it; it makes my life as a schema writer a little bit harder, for, afaict, not much benefit, although I can see doing this for specific reasons related to implementation concerns or composability.

If that's not the case, it would be nice to have a way to say "this is a check on the propertyNames of any properties that do not already get checked for by properties", or perhaps allow a regex in properties.

[gregsdennis]

it would be nice to have a way to say "this is a check on the propertyNames of any properties that do not already get checked for by properties"

I understand your concern, and that seems like a valid option that JSON Schema could support. Perhaps an unevaluatedPropertyNames keyword is in order (to go along with unevaluatedProperties).

or perhaps allow a regex in properties

The problem with this is that the keys in properties are explicit property names in a JSON object, and as far as JSON is concern any regex could be a valid property name.

[strega-nil]

alright, sounds good! Thanks for taking my idea into consideration :)

[gregsdennis]

No problem. It'll be in consideration for future drafts. We like to leave new feature suggestions open for a long time so that as many people as possible can get their opinions in.

But don't despair! Draft 8 brings in vocabularies, so if you find a draft 8 implementation, you should be able to define the keyword yourself and let us know how you get on.

[handrews]

@ubsan why not just use patternProperties? It does what you want.

[strega-nil]

@handrews because I did not know about it at the time :P

I ended up not doing the additionalProperties: false thing :)

[handrews]

@ubsan additionalProperties: false is usually more trouble than it's worth IMHO. Since patternProperties would have worked, it's not clear what else this proposal would do.

The other string assertions (minLength and maxLength) can also be implemented as patterns, and format's behavior is too unreliably implemented to be useful here. If a clear use case arises, it can be filed as a new issue.