What about an isRequired keyword?

[sheinzle]

We're working on client project with a huge flat input JSON file, with > 100 entries on the top level.

In such a setting, the required keyword becomes unmaintainable: when adding a new property or renaming a property, the required-list might get forgotten. Furthermore, as schema developer, it's not so clear on first sight which properties are actually required and which are not.

As I understand, there are already long discussions on how to support a require-all #659 , but what about turning around the require approach instead? Consider the following syntax:

{
    "properties": {
        "foo": {"type": "integer", "isRequired": true},
        "bar": {"type": "integer", "isRequired": true},
        "notRequired": {"type": "integer", "isRequired": false},
        "alsoNotRequired": {"type": "integer"}
        ... 100 more entries
    }
}

This way, we don't need the required keyword.

• Each of the properties themselves can specify if they are required.
• Renaming a property only needs one touchpoint, not modifying two source locations.
• It is immediately clear, if a property is required or not.
• And it should also work when combining schemas.

Disclaimer - I'm fairly new to the JSON schema, maybe I am missing a crucial bit.

[awwright]

"required" actually worked this way in earlier versions, and several validators still support this usage. Check draft-3, I believe. The primary argument for the array form is it's more consistent with the way other keywords work; whereas the boolean form could take potentially different meanings depending on the context. For example, a schema {required: true} is meaningless, the keyword was only meaningful if that schema was itself found inside a "properties" keyword. No other keyword worked like that. I argued at the time I like the boolean form because it's an author convenience, it's not difficult to convert between the two if you have enough context. Another idea is a "requiredProperties" keyword, like "properties" but where all the listed properties are also required. There might be an open issue for it, lemme get back to you tomorrow.

…

On Mon, Apr 29, 2019, 08:33 Simon Heinzle ***@***.***> wrote: We're working on client project with a huge flat input JSON file, with > 100 entries on the top level. In such a setting, the required keyword becomes unmaintainable: when adding a new property or renaming a property, the required-list might get forgotten. Furthermore, as schema developer, it's not so clear on first sight which properties are actually required and which are not. As I understand, there are already long discussions on how to support a require-all #659 <#659> , but what about turning around the require approach instead? Consider the following syntax: { "properties": { "foo": {"type": "integer", "isRequired": true}, "bar": {"type": "integer", "isRequired": true}, "notRequired": {"type": "integer", "isRequired": true}, "alsoNotRequired": {"type": "integer"} ... 100 more entries } } This way, we don't need the required keyword. - Each of the properties themselves can specify if they are required. - Renaming a property only needs one touchpoint, not modifying two source locations. - It is immediately clear, if a property is required or not. - And it should also work when combining schemas. Disclaimer - I'm fairly new to the JSON schema, maybe I am missing a crucial bit. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#734>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADK2DIKRXSZ2WNCRILN47TPS4IOJANCNFSM4HJEMYTA> .

[handrews]

I'm going to close this in favor of requiredProperties as explained in #846. That issue includes a detailed explanation of why a boolean keyword such as isRequired (which was actually how required worked way back in draft-03) is not possible.