OpenAPI / Swagger 2.0: Default discriminator value

Question

I am using Swagger 2.0 to define our API contract schema where we are planning to use polymorphism with discriminator. I have a parent class (named Animal) and two child class extending Animal for now (Dog/Cat). Animal would have a field animalType which would be used to identify the animal class type. I want to have multiple animal type like "Dog", "Cat", "Horse", "Cow" and mapping between animalType and model would look like this -

Dog -> Dog

Cat -> Cat

Horse -> Animal

Cow -> Animal

If there is no schema defined for animalType Horse/Cow, then by default Animal would get picked up. Is my understanding correct ?

Can someone please help if below schema works or how I would make it work ?

Below is the schema which i am trying to create but cannot test in swagger 2.0 editor as it doesn't support discriminator - https://editor.swagger.io/?url=https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/examples/v2.0/yaml/api-with-examples.yaml

components:
  schemas:
    Animal:
      type: object
      required:
      - animalType
      properties:
        animalType:
          type: string
           enum:
            'Dog'
            'Horse'
            'Cow'
            'Cat'
        name:
            type: string
      discriminator:
        propertyName: animalType
    Cat:
      - allOf:
        - $ref: '#/components/schemas/Animal'
      - type: object
        # all other properties specific to a `Cat`
        properties:
          color:
            type: string
      - x-ms-discriminator-value: 'Cat',
    Dog:
      - allOf:
         - $ref: '#/components/schemas/Animal'
      - type: object
        # all other properties specific to a `Dog`
        properties:
          bark:
            type: string
      x-ms-discriminator-value: 'Cat'

Answer 1

The discriminator concept exists to help processing software which needs to parse instance data conforming to an OpenAPI specification, such as validators, serializers, and to a lesser extent, code generators, work with the schema constructs oneOf, anyOf, and allOf.

OpenAPI schema types defined using these constructs are difficult for processors to work with, because the sub-schemas defined under them are often quite different and in order to determine the appropriate sub-schema when encountering potentially conforming data, it is necessary to try them one by one until a match is found.

Discriminators allow OpenAPI specification authors to circumvent this problem by defining an explicit value match on the conforming data to determine the relevant sub-schema to use, which is great!

However, a processor will only respect explicitly defined sub-schemas. If the differentiator value indicates a sub-schema should be used which then turns out to just not exist, your average processor will simply fall over in a messy heap rather than start "inventing" sub-schemas, and regardless of actual implementation we should certainly not have this expectation.

If there is no schema defined for animalType Horse/Cow, then by default Animal would get picked up. Is my understanding correct ?

This is all a rather long-winded way of saying two things: no, your understanding of the purpose of discriminators is not correct, and secondly (and somewhat tangentially), your desire to expose polymorphic behavior over your API boundary should be tempered by the knowledge that doing so makes your API's design waaaaaay more complicated than it needs to be; in the vast majority of use-cases, simple mono-morphic models are all you need.