More review feedback.

Author: handrews

Diff for: versions/3.1.1.md

@@ -196,7 +196,7 @@ If the same JSON/YAML object is parsed multiple times and the respective context
 Several features of this specification require resolution of non-URI-based connections to some other part of the OpenAPI Description (OAD).
 ``
 
-These connections are easily resolved in single-document OADs, but the resolution process in multi-document OADs has never been spelled out, and is therefore _implementation-defined_, within the constraints described in this section.
+These connections are unambiguously resolved in single-document OADs, but the resolution process in multi-document OADs is _implementation-defined_, within the constraints described in this section.
 In some cases, an unambiguous URI-based alternative is available, and OAD authors are RECOMMENDED to always use the alternative:
 
 Source | Target | Alternative
@@ -206,22 +206,23 @@ Source | Target | Alternative
 [Operation Object](#operationObject) `tags` | [Tag Object](#tagObject) `name` (in the Components Object) | _n/a_
 [Link Object](#linkObject) `operationId` | [Path Item Object](#pathItemObject) `operationId` | `operationRef`
 
-A fifth 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.
+A fifth implicit connection involves appending the templated URL paths of the [Paths Object](#pathsObject) to the appropriate [Server Object](#serverObject)'s `url` field.
+This is unambiguous because only the entry document's Paths Object contributes URLs to the described API.
 
 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.
+This requires parsing all referenced documents 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 appropriately typed sub-object of the Components Object.
 For example, the component name of the Schema Object at `#/components/schemas/Foo` is `Foo`.
-The implicit connection of `tags` in the Operation Object use the `name` field of Tag Objects, which (like the Components Object) are found under the root OpenAPI Object.
+The implicit connection of `tags` in the Operation Object uses the `name` field of Tag Objects, which (like the Components Object) are found under the root OpenAPI Object.
 This means resolving component names and tag names both depend on starting from the correct OpenAPI Object.
 
 For resolving component and tag name connections from a referenced (non-entry) document, it is RECOMMENDED that tools resolve from the entry document, rather than the current document.
 This allows Security Scheme Objects and Tag Objects to be defined with the API's deployment information (the top-level Server Objects), and treated as an interface for referenced documents to access.
 
 The interface approach can also work for Discriminator Objects and Schema Objects, but it is also possible to keep the Discriminator Object's behavior within a single document using the relative URI-reference syntax of `mapping`.
 
-There currently are no URI-based alternatives for the Security Requirement Object or for the Operation Object's `tags` field.
+There are no URI-based alternatives for the Security Requirement Object or for the Operation Object's `tags` field.
 These limitations are expected to be addressed in a future release.
 
 Note that no aspect of implicit connection resolution changes how [URIs are resolved](#relativeReferencesURI), or restricts their possible targets.