Section "Keyword independence" is written twice

[awwright]

The section "Keyword independence" is a short little section that describes how keywords don't (usually) interact with each other, and that this is a design consideration of JSON Schema. It lists some of the exceptions to this rule.

However, somewhere along the lines, this section was duplicated:

10.1. Keyword Independence
11.1. Keyword Independence

The doppelgänger should be removed.

[Relequestual]

It's not identical. The list of exceptions are different and specifically related to the vocabulary, hence being a subsection.

[awwright]

Nonetheless, the purpose of the section is to lay down the design considerations of JSON Schema as a whole, it's not necessary to duplicate it for each vocabulary.

[karenetheridge]

I thought we resolved this in an earlier PR for the interim draft revision. Perhaps that PR was closed without merging?

[Relequestual]

@karenetheridge I had a quick look but coudln't find anything relating to this, closed or otherwise.
If you find anything, let us know.

[gregsdennis]

@karenetheridge I think I found what you were referring to. (The change below was after you commented.)

The current text now has this:

json-schema-spec/jsonschema-core.md

Lines 487 to 511 in a29508c

	### Keyword Interactions
	Unless otherwise specified, keywords act independently.
	Keywords MAY modify their behavior based on the presence, absence, or value of
	another keyword in the same schema object. Such keywords MUST NOT result in a
	circular dependency.
	Supplementary specifications are encouraged to specify any dependencies as part
	of the dependent keyword (i.e. the keyword whose behavior is modified).
	Within this document, keyword dependencies are expressed using one of the
	following mechanisms:
	- Static dependencies, in which the dependency relies on the presence or
	contents of another keyword.
	- Dynamic dependencies, in which the dependency relies on the evaluation of
	another keyword against an instance. This dependency may be on either the
	annotations produced by the keyword or the validation result of its
	subschema(s).
	These mechanisms are used merely to describe dependencies; they are for
	illustrative purposes and not prescriptive. Implementations MAY use whatever
	mechanisms make sense given the needs of their architecture and language in
	order to achieve the specified behaviors.

The first part of this seems like it works to resolve this. What remains is removing the text from the other sections.