I think this keyword should be moved out of this section entirely -- as it is presently located in "Keywords for Applying Subschemas to Arrays". It can be moved to a third section after "Keywords for Applying Subschemas to Objects", called "Keywords for Applying Subschemas to Arrays or Objects", or even just "Other Keywords for Applying Subschemas".

What happens if someone wants to specify that an array to contain an item, OR that an object to contain a property value?

I would like to suggest these should be different keywords, e.g. containsItem or containsValue/containsProperty

What happens if someone wants to specify that an array to contain an item, OR that an object to contain a property value? - @awwright

If they only wanted one or the other, they would need to also specify type, which is the current solution to that need anyway.

@awwright If you think this needs more discussion, please comment on #1077. I'm happy to put this PR on hold until consensus is achieved, but that discussion should take place on the issue, not here.

Good thinking about adding to the change log! It sounds like this PR might get closed as preference seems to be shifting toward using new keywords. When it's decided, I will make sure whichever one we go with is included in the changelog.

While it sounds like this PR is a bit in-limbo, if that changes and it's re-approved, it would be good to wait to merge until we decide whether to branch for the next major draft.

It appears we have general consensus on this direction, so I'm removing "draft" status to open this up for review. However, @handrews, I will not merge until we decide what's happening with the bug-fix draft. This should not be included in the bug-fix draft.

I had the create a new section for the change log because it doesn't exist yet. I used draft-bhutton-json-schema-next as the draft identifier because it's not certain which draft we will be on when this gets released if there are one or more bug-fix drafts. It will have to be updated when the next full draft release is near.

I just want to include a quick summary of the discussion around adding this keyword.

There was no opposition to adding contains-like functionality that applies to objects. This functionality was already possible in JSON Schema using the following pattern.

{
  "not": {
    "patternProperties": {
      "": { "not": { ... schema ... } }
    }
  }
}

Note: I used patternProperties instead of additionalProperties to make it explicit that it should not be affected by defined properties.

The only point of contention was whether contains should apply to objects as well as arrays, or there should be new keywords that only apply to objects. Using the same keyword could result in backwards incompatible behavior in very rare (and poorly designed) situations. But it can also be useful such as describing a value that can be an object or an array, but either way, it must contain some value. However, the main benefit of using the same keywords is that it's easy for schema authors to understand and allows us to avoid adding three new keywords.

In the end, the only people expressing strong preferences were for overloading contains and there was only one person with a slight preference for new keywords. So, went with overloading contains.

I noticed there were no changes to meta/applicator.json. Shall we do those in a subsequent PR?

I don't think there are any meta-schema changes needed for this. Am I missing something?