Field required based on condition

[brunodymios]

It is very common to have data structures in which a field becomes required only if a particular condition holds. For example, having a field A being required only if field B has been specified is something easily achievable with draft-07 specification using dependencies or if-then-else constructs.

However, very commonly, a field is required only if a particular boolean condition is true. More in general, let's suppose to have numeric fields A, B and C and that field A is required only if B > C.

How to accomplish that? My understanding about draft-07 specification is that this is not possible, however it could be very useful.

I think that the best solution could be to change the current specification of the required property: "required": { "$ref": "#/definitions/stringArray" } to something more complex, supporting the specification of objects instead of a stringArray, giving the possibility to specify boolean conditions. Something like the following:

{
    "title": "test",
    "type": "object",
    "properties": {
      "A": { "type": "number" },
      "B": { "type": "number" },
      "C": { "type": "number" },
    },
    "required": [
      { 
        "key": "A",
        "condition": "B > C"
      },
    ]
}

Do you think this makes sufficiently sense to work on it and open a dedicated PR?

Thank You

[handrews]

@brunodymios this seems to be combining two things:

1. conditional requirement of properties
2. conditions expressed as relationships among properties

The first part can be implemented today with if:

{
    "properties": {"A": {...}, ...},
    "if": {"$comment": "some schema expressing the condition", ...},
    "then": {"required": ["A"]}
}

The second part is the $data proposal, as filed in issue #51. With that proposal and if, your example would look like:

{
    "title": "test",
    "type": "object",
    "properties": {
      "A": { "type": "number" },
      "B": { "type": "number" },
      "C": { "type": "number" },
    },
    "if": {
        "properties": {
            "B": {
                "exclusiveMinimum": {
                    "$data": "1/C"
                }
            }
        }
    },
    "then": {
        "required": [ "A" ],
    }
}

The "1/C" is a relative JSON pointer that means 'the "C" property in the same object as this current property' (1 means to go up one level, from this property to the object containing it, and then down into the C property of that object).

That's just an example based on the current $data proposal, which is controversial both because it's a major expansion of scope for JSON Schema, and because we're not sure it's the best form for expressing this (you can see how much more verbose the if + $data version is).

I expect $data to be the primary focus of draft-09.

If it's OK with you I'd prefer to close this and keep the discussion of $data in #51. We have if as a general conditional mechanism and would like to avoid a proliferation of special case conditionals (I'd personally love to get rid of the one special case we have- dependencies, but we seem to be stuck with it much to my frustration).

So really this just boils down to $data again.

[brunodymios]

@handrews I know that the roadmap is somehow set and I don't want to open parallel discussions so I'm ok with closing this issue.

I've just another question that I think it is related to point 2. What about having a requirement saying that field A must be always equal to field B divided by field C?
Consider the case in which we are managing financial data and we need this information to both show in a form the auto-computed value and validate/recompute this value server-side.

Is this currently being addressed? Could you in case redirect me to an already existing issue in order to let me follow the discussion?

Thank You

[handrews]

@brunodymios I think that in addition to the basic $data question (can we reference data for schema keyword values) there would likely be questions about how much we can do with said values.

I don't think there is an issue for expressions built on $data, so you are welcome to open that. I am still going to close this b/c it is combined with the basic conditional and $data concerns which already have issues.

I'm skeptical about implementing general expressions, but that doesn't mean you shouldn't file it and see what other ideas pop up. $data and draft-09 in general will be about how much of this stuff should really be in scope for JSON Schema, or at least for the main standardized vocabularies. There are use cases for many, many things, but at some point we need to say "OK, that's a job for another technology" or else we're re-implementing JavaScript.

BTW, the roadmap isn't very "set". The reason I'm saying it's draft-09 is just that the issues that we're already deep into debating and about to write up into PRs are plenty sufficient for publishing a draft-08 so I don't want to throw another huge topic into that draft. If something else came up to make better to pursue things in a different order, we'll do that. Or if more people are able to manage the debates that will let us work on more things (up to a point, anyway).

[brunodymios]

I agree with you @handrews, thanks.

I'm going to file the question about general expression as a separated issue, as you suggested.

[brunodymios]

Created issue #541

[sreedhar85]

I have scenario:
This is json request.
"address": [
{
"addressTyp": "Home",
"addressLine1": "",
"city": "",
"state": "",
"zip": "",
"country": ""
},
{ "addressTyp": "Mailing",
"addressLine1": "",
"city": "",
"state": "",
"zip": "",
"country": ""
}
]
json schema validation:
"required": [
"addressType",
"addressLine1",
"city",
"state",
"zip",
"country"
]
Scenario:
if addressType="Home" then Need to validate the all required fileds of first addresss item like
address[0].addressLne1, address[0].city, address[0].state, address[0].zip, address[0].country
else addressType="Mailing" then It's should ignore the all Required fileds validation, all required filelds are not mandatory

Corrrently: it's validating irrespective of addressType value 'Home" and "Mailing", it should validate required fields only if addressType="Home" and should ignore for addressType="Mailing"

[awwright]

@sreedhar85 This repository is for discussing changes to the specification, if you need assistance with authoring schemas try the mailing list, Slack, IRC, or StackOverflow . Check out the JSON Schema website for more information.