Improve wording from review feedback

Also fix an incorrect section anchor.

Author: handrews

versions/3.1.1.md

@@ -188,7 +188,7 @@ When parsing an OAD, JSON or YAML objects are parsed into specific Objects (such
 
 If the same JSON/YAML object is parsed multiple times and the respective contexts require it to be parsed as _different_ Object types, the resulting behavior is _implementation defined_, and MAY be treated as an error if detected.  An example would be referencing an empty Schema Object under `#/components/schemas` where a Path Item Object is expected, as an empty object is valid for both types.  For maximum interoperability, it is RECOMMENDED that OpenAPI Description authors avoid such scenarios.
 
-#### <a name="resolvingIndirectLinkages"></a>Resolving Indirect Connections
+#### <a name="resolvingIndirectConnections"></a>Resolving Indirect Connections
 
 Several features of this specification require resolving a non-URI-based connection to some other part of the OpenAPI Description (OAD).
 
@@ -204,13 +204,15 @@ Source | Target | Alternative
 A fourth implicit connection, which involves appending the templated URL paths of the [Paths Object](#pathsObject) to the appropriate [Server Object](#serverObject)'s `url` field, is unambiguous because only the entry document's Paths Object contributes URLs to the described API.
 
 For resolving indirect connections from a referenced (non-entry) document, it is RECOMMENDED that tools support one or both of the following approaches, and it is likewise RECOMMENDED that OAD authors organize their documents to work well with them.
+Note that neither approach changes how [URIs are resolved](##relativeReferencesURI), or restricts their possible targets.
 
 ##### OADs Using Only Complete Documents
 
-The approach in this section is RECOMMENDED for OADs that are composed entirely of complete OpenAPI documents, optionally including standalone JSON Schema documents as long as any Discriminator Objects within them only use explicit `mapping` URIs for all possible values.
+The approach in this section is RECOMMENDED for OADs that are composed entirely of complete documents.
+Standalone JSON Schema documents can be included along with complete OpenAPI Documents as long as any Discriminator Objects within the standalone JSON Schemas only use explicit `mapping` URIs for all possible values.
 This OAD design is RECOMMENDED when sharing components among multiple OADs.
 
-In this approach, each document is self-contained and resolves components to its own Components Object.
+In this approach, each document is self-contained and resolves component names to its own Components Object.
 When resolving an `operationId`, all Path Item Objects from all parsed documents are considered.
 This requires ensuring that all referenced documents have been parsed prior to determining an `operationId` to be unresolvable.