Assert that value must appear once somewhere else in JSON

[caleb531]

Hi there,

As far as I know, this would be considered a feature request because I haven't found a way to do in via any features available in the current Draft-07 JSON Schema. The title of this issue sounds slightly strange, but the idea is extremely simple.

Consider the following JSON:

{
  "favorite_animal": 32,
  "animals": [
    {
      "id": 57,
      "name": "Llama"
    },
    {
      "id": 32,
      "name": "Red Panda"
    },
    {
      "id": 95,
      "name": "Otter"
    }
  ]
}

My aim is to have some schema-driven way of asserting that favorite_animal maps to an id of one of the objects in the animals array. Specifically, it must map to exactly one id, but depending on how this is implemented, it could be implemented in the spirit of the oneOf, anyOf, and allOf family of keywords.

Is this already possible via some means of $ref and whatnot, or am I out of luck? If the latter, is this use case seem practical and useful enough to warrant crafting functionality for it in JSON Schema?

Thanks,
Caleb

[awwright]

I call this kind of validation consistency validation because it involves checking that two pieces of data are consistent with each other. In other applications, this might also be called entailment, or other things.

Typically we haven't dealt with this because it's very difficult to define completely. There might be mathematics or data operations involved, for example, and it's impractical to define a whole scripting language out of JSON.

Another reason I'm skittish on this is I don't want to cause people to structure their JSON documents around the features of JSON Schema, and this feature might cause people to produce bloated JSON documents, when otherwise it'd be preferable to just write a standard database query.

But there might be a generic way to define this, #549 suggests a property that can define data sources, and data references, and validators can implement user functions to verify a data reference points to a member of a data source.

There might be a few other issues about this. Give me a few days to check, or maybe someone else remembers?

This is a frequent enough question we should probably consider treating it in the spec text.

[awwright]

I think the issue for this is #340, if that's your issue you can consider closing this @caleb531

[caleb531]

@awwright That's all very fair, and I agree that #340 is in the spirit of what I am desiring to do (disregarding exact semantics, because I'm not aiming to be picky). Closing this now—thanks for the feedback.