anyOf and polymorphism

[zorba128]

Hi

When discussing polymorphism handling in libraries we use for json schema/openapi/asyncapi, I somehow started thinking about anyOf.
I'm wondering now, is there any real-life example, where anyOf models some business requirements?
I come from scala, which is actually pretty good at modeling data. And I cant imagine where I would need anyOf like behavior.

I'm not thinking about imaginary cats and dogs or foobars data model - think of system that accepts and processes some data input. And has some reasonable business logic, accepting request with json payload and taking some decision that matches anyOf spec.
Like endpoint that retreieves list of log entries, endpoint for placing new payment request, endpoint for issuing new order request to the exchange, endpoint for authenticating user credentials - whatever. Is there any business need that requires anyOf on the input?

Somehow I feel specs use anyOf as a workaround, where the feature that is really need is not available.
At least when it comes for modeling polymorphism - and this how it gets explained in all examples.

If you ever really needed it, please drop some example.

marcin

[gregsdennis]

anyOf is one of many keywords that JSON Schema started with. I'm not sure anyone currently involved with this project could speak to why they were included. I will say that anyOf, allOf, oneOf, and not do provide a means to declare boolean combinations that would otherwise be impossible.

Beyond structural validation (which is the polymorphism argument), you can do all kinds of value validation. I know you've asked for a model that's not contrived, but I don't have that kind of data. So I'll contrive one for you that seems like it'd be a pretty legitimate requirement.

Let's model a person. As part of our person, we want to include both an age property as well as ageBracket property, but we need to validate that ageBracket is appropriate for the age given. Simplistically, I'd do something like this:

{
  "properties": {
    "age": { "type": "integer", "minimum": 0 },
    "ageBracket": { "enum": [ "child", "adult", "senior" ] }
  },
  "anyOf": [
    {
      "properties": {
        "age": { "maximum": 17 },
        "ageBracket": { "const": "child" }
      }
    },
    {
      "properties": {
        "age": { "minimum": 18, "maximum": 64 },
        "ageBracket": { "const": "child" }
      }
    },
    {
      "properties": {
        "age": { "minimum": 65 },
        "ageBracket": { "const": "senior" }
      }
    },
  ]
}

The reason I'd use anyOf instead of oneOf here is because the options are mutually exclusive. As soon as one of the subschemas matches, we know the others don't match. This allows shortcutting.

---

In regards to deprecating the keyword, I don't see that it being available is causing any problems. If you don't want to use it, then don't. We'd have to have a pretty strong case against it (such as its use is causing harm or there's a security risk) in order to deprecate it, especially since it's so ubiquitous.

[jdesrosiers]

The boolean algebra keywords allOf (AND), anyOf (OR), oneOf (XOR), and not (NOT) are intended for declaring compound validation constraints. They aren't designed for anything related to polymorphism. Using any of these keywords to model polymorphism is dubious. JSON Schema isn't designed for that kind of thing.

A common use of anyOf is to assert that at least one of a set optional properties is required. A realistic example would be a customer record that requires a customer provide some way of contacting them, but gives them the option to provide at least one of a phone number or an email address.

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "phoneNumber": { "type": "string" },
    "email": { "type": "string" },
    ...
  },
  "required": ["name", ...],
  "anyOf": [
    { "required": ["phoneNumber"] },
    { "required": ["email"] }
  ]
}

[zorba128]

Thank you for detailed explanation. Most probably my question is more related to openapi/asyncapi (which heavily derive from - and use json schema) and puts semantic layer on top of it. Thanks again for great explanation.