Indirect->Implicit, unify operationId, more tweaks

Every time I try to reference this section in another PR I type
"implicit" instead of "indirect" so let's just go with that.

Let's also treat `operationId` uniformly, because it fits better
with how we parse documents, and the only thing this changes
is in the only-the-entry-document-has-an-OpenAPI-object case,
where it incorporates Path Item Objects in the entry document
that are otherwise un-referenced.  It seems likely that one would
only include Path Item Objects in the entry document's components
if one expected them to be used.

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="resolvingIndirectConnections"></a>Resolving Indirect Connections
+#### <a name="resolvingImplicitConnections"></a>Resolving Implicit Connections
 
 Several features of this specification require resolving a non-URI-based connection to some other part of the OpenAPI Description (OAD).
 
@@ -203,7 +203,12 @@ 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.
+It is RECOMMENDED to consider all Operation Objects from all parsed documents When resolving any Link Object `operationId`.
+This requires ensuring that all referenced documents have been parsed prior to determining an `operationId` to be unresolvable.
+
+The implicit connections in the Security Requirement Object and Discriminator Object rely on the _component name_, which is the property name holding the component in the appropriate typed sub-object of the Components Object.
+For example, the component name of the Schema Object at `#/components/schemas/Foo` is `Foo`.
+For resolving component name 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
@@ -213,8 +218,6 @@ Standalone JSON Schema documents can be included along with complete OpenAPI Doc
 This OAD design is RECOMMENDED when sharing components among multiple OADs.
 
 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.
 
 **Note:** Currently, Security Requirement Objects do not support a URI-based mechanism for connecting to Security Scheme Objects, which means that in this approach, they can only connect to Security Schemes within the same document.
 This limitation is expected to be addressed in a future version of this specification.