Proposal: remove propertyNames #768
Replies: 4 comments 30 replies
-
I think you mean that you can't reference it with a JSON Pointer. I've noticed this as well and have considered whether that means
None of this makes sense to me. I don't understand the problem you're trying to describe. Whatever it is, I don't think I've encountered it. In my implementation, the only issue I encountered was that JSON Pointer can't point to a property name, but that's only a problem for the output format. It doesn't affect the algorithm at all. |
Beta Was this translation helpful? Give feedback.
-
In 2300 schema files from schemastore I couldn't find anything like that. Of course, it also depends on what you mean by clean, of course propertyNames is the cleanest, only that it allows even simple errors, and from my point of view the following are quite clean: for allowing exact names or patterns (with desired pattern instead of this in example): {
"$id": "https://json-schema.hyperjump.io/schema",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type":"object",
"patternProperties": {"^(foo|bar)$": true},
"additionalProperties": false
} Note: allowing property names without defining a schema for the values is another non-sense IMO, the proof of that is the rare use of this for deniying names: {
"$id": "https://json-schema.hyperjump.io/schema",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type":"object",
"not": {"anyOf": [ {"required": ["foo"]}, {"required": ["bar"]}]}
}
Now take a look at this schema, I used your implementation, but I'm sure would produce the same result with any implementation due to the reasons I presented regarding the algorithm: {
"$id": "https://json-schema.hyperjump.io/schema",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type":"object",
"propertyNames": {"propertyNames":{"type":"boolean"}},
"allOf": [{"propertyNames": {"propertyNames":{"type":"boolean"}}}]
} A non-sense schema like this is perfectly valid and would validate any object. And this is just a quick example, basically any schema valid against metaschema would validate the object. In fact this is a broader problem in
Without this "small" issue the algorithm would work without checking for |
Beta Was this translation helpful? Give feedback.
-
what I saw in schemastore schemas people are using much more often the following instead of properties: {
foo: {},
bar: {},
baz: false
} The intent is even more clearer like that, and for the pattern cases there is |
Beta Was this translation helpful? Give feedback.
-
To me, a conversation about removing any keyword needs to consider both its longevity and how complete its definition is.
Given that, I don't think the arguments presented warrant removal from the specification. I'm going to close this discussion, but it will remain unlocked. |
Beta Was this translation helpful? Give feedback.
-
The keyword
propertyNames
doesn't fit injson-schema
algoritm and IMO should be removed.Motivation
I searched for the presence of this keyword in 2300 schemes, I found 109 instances of which about half were stupid like
type: string
, about a quarter were enum or not enum, and the others were pattern. None of those instances were something that could not be replaced by other schemas.Beta Was this translation helpful? Give feedback.
All reactions