Discriminator field (unnecessarily) required

Is it possible to remove the restriction of making the field that acts as discriminator required (and assume that when not returned, the object is just of the ‘base’ type defined in the schema)?

i.e (using the Pet example from the docs)

Schema:

(...)
properties: 
    pets: 
       type: array
       items:
           type: Pet

Payload:

{
   pets: [
   {
      name: "Some generic pet" 
   },
   {
      @type: Dog
      name: "Some dog"
      packSize: ...
   },
   {
      @type: Cat
      name: "Some cat"
      huntingSkill: ...
   },
   {
       name: "Some other generic pet"
   }
}

The first and third items are just of type “Pet” which would be explicit from the schema of the “pets” field. “Pet” would therefore define the @type field but it won’t be required. We use schema.org and rely on polymorphic schemas extensively but we currently only return a type discriminator when is not obvious from the schema (i.e when returning a subtype). Unless I misunderstand it, adhering to the spec would require us to return @type everywhere which would significantly increase payload size (and thus would prob be a non-starter).

Let me know if you have any thoughts or reasons to not go this route.

[handrews]

@Relequestual discriminator does not fit well with other aspects of JSON Schema- I looked into it while we considered if/then/else and again during the whole unevaluatedProperties saga. I’d have to do some digging to explain exactly why.

[tmtron]

another use-case for an optional discriminator is API-evolution.

i.e. we may have an API that only supports one type (e.g. Dogs) and thus has no discriminator But later we need to add support for Cats

Then we can change the API in a backwards compatible way

• original Dog objects (without discriminator will still work)
• new Dog object with discriminator Dog will now also work
• new Cat objects must have a discriminator