Support for required additionalProperties in schema

[Vasfed]

When specifying additionalProperties fields as required there's no indication of these.

Example schema:

openapi: 3.0.2
info:
  title: Test
  version: "0.0.1"
paths:
  /example:
    get:
      summary: Example operation
      responses:
        '200':
          description: ok
          content:
            application/json:
              schema:
                allOf:
                  - type: object
                    description: dynamic fields, expect to see `prop1` and `prop2` as required field names here
                    additionalProperties:
                      type: string
                  - required:
                    - prop1
                    - prop2
              example:
                prop1: required prop
                prop2: required prop
                prop3: optional prop

[m-mohr]

If there are two fields with a fixed name prop1 and prop2, you should probably just list them as properties.

[Vasfed]

If there are two fields with a fixed name prop1 and prop2, you should probably just list them as properties.

This workaround loses clarity for documentation reader about these fields belonging to the same entity. Also induces spec code duplication (in required for validation and in properties to show up in docs, which should be in sync). Initial usecase is producing reusable object with urls to different formats and sizes of the same single image.

More generally speaking - I think we should not silently ignore fields from required, if these are not listed in properties

[handrews]

@Vasfed that's really more of a JSON Schema issue. Those fields are being handled as designed, but there's a proposal for a combination requiredProperties field that has a fair amount of support and seems targeted for the next draft.
json-schema-org/json-schema-spec#846