Documentation of schema with allOf changes based on presence of an attribute in one of the included schemas

[jpjpjp]

Documentation of schema with allOf changes based on presence of an attribute in one of the included schemas

[brendarearden]

Thank you for providing all the details!

Looking at your spec, we believe that changing additionalProperties: false in your baseObject to additionalProperties: true would resolve the issue you are seeing. Would you try this and let us know?

[weyert]

Yeah, that will fix it. I am having the same issue only I am not sure what the expected behaviour of allOf is regarding merging two schemas. Should it ignore additionalProperties?

[jpjpjp]

Hi @brendarearden and @weyert. Sorry for the late response. Indeed it does fix the problem but doesn't give me the desired result which is a new object that combines the properties of the baseObject along with the new properties in the publicBaseGroupObject AND applies the additionalProperties:false property the new combined set of properties.

I realize this isn't necessarily an elements issue, but does OpenAPI support something like:

# In components/schemas...
baseObject:
  type: object
  properties:
    basePropertyOne:
      type: string
    basePropertyTwo:
      type: int

superObject:
      description: >
        The object is a superset of the baseObject.  It includes everything
        that the baseObject has, but also additional parameters.
        We want the documentation for this object to show this description as 
        well as expanding to show the doc strings for the attributes in the 
        baseObject and extra attributes added here.
        We also want the additionalProperties attribute to apply allow all
        the properties defined here but cause errors in validation if others
        exist
     additionalProperties: false
      allOf:
        - $ref: '#/components/schemas/baseObject'
        - type: object
          properties:
            superPropertyOne:
              type: string

Such that a superObject that looks like this:

{
  "basePropertyOne": "foo",
  "basePropertyTwo": 2,
  "superPropertyOne": "bar"
}

Is valid, but one that looks like this:

{
  "basePropertyOne": "foo",
  "basePropertyTwo": 2,
  "superPropertyOne": "bar",
  "extraProperty": "baz"
}

Fails validation because of it is an additionalProperty at the "superObject" level?

What I've found is that an additionalProperties: false setting seems to apply only to the baseObject and actually causes validators to complain about "superPropertyOne" (and also the generated docs don't look good).

[weyert]

Yes,I tried to read the JSON schema specification about how allOf merge behaviour should be when additionalProperties is used. Only I can't figure it out. If you look at the behaviour of Redocly it appears to somehow ignore it?

They do have a page describing allOf here:
https://redocly.com/docs/resources/all-of/

I do wonder if the validation should differ from what is shown in schema viewer in Elements?

I have the feeling that Redocly always merges the schemas and ignores additionalProperties-setting when displaying the schemas. A similar functionality can be achieved by setting the ignoreAdditionalProperties in @stoplight/json-schema-merge-allof

ignoreAdditionalProperties default false

Allows you to combine schema properties even though some schemas have additionalProperties: false This is the most common issue people face when trying to expand schemas using allOf and a limitation of the json schema spec. Be aware though that the schema produced will allow more than the original schema. But this is useful if just want to combine schemas using allOf as if additionalProperties wasn't false during the merge process. The resulting schema will still get additionalProperties set to false.