Henry Andrews

@ahmednfwela in practice, it's probably not. But we can't do the preferred option of forbidding `null` for attributes in 3.2 because that would break compatibility with 3.1. (we don't want...

@ahmednfwela we can't do anything that contradicts specified behavior in OAS 3.1.

Hmm... I do see your point, @ahmednfwela . I'm kind of at the point of throwing my hands up on this and saying that if you try to use `type:...

@ahmednfwela I've continued to think about this, and I think the concern about constructs like: ```yaml properties: someElement: required: - someAttribute properties: someAttribute: type: [number, "null"] xml: attribute: true ```...

This ended up getting fixed for 3.2 in PR #4612, so closing.

@tedepstein > JSON Schema tried to agree a merge feature, put a lot of effort into this, but ultimately had to abandon those efforts. Maybe we should get some input...

@tedepstein > Could we think of traits (or mixins), and trait application, as a separate layer of processing, similar to a schema generator? That possibility for `$merge` was discussed extensively....

@mkistler > If that's a problem, we could require that mixins specify their `type` (that was in my original proposal, but @darrelmiller suggested we make it optional). Making `type` required...

@mkistler @darrelmiller @MikeRalphson @tedepstein given https://github.com/OAI/OpenAPI-Specification/pull/1865#issuecomment-472953005 it sounds like there's not much point in me writing up why this is such a problem for JSON Schema. I'm still happy to...

@tedepstein OK, after a lot of thought, I've distilled this down to a relatively concise explanation. Part of the problem with `$merge` is potentially unexpected behavior as large systems grow...