graphql · benjie · Oct 18, 2021 · Apr 28, 2023 · Apr 28, 2023 · Aug 21, 2023
diff --git a/spec/Section 3 -- Type System.md b/spec/Section 3 -- Type System.md
@@ -328,7 +328,7 @@ GraphQL supports two abstract types: interfaces and unions.
 An `Interface` defines a list of fields; `Object` types and other Interface
 types which implement this Interface are guaranteed to implement those fields.
 Whenever a field claims it will return an Interface type, it will return a valid
-implementing Object type during execution.
+implementing Object type during _execution_.
 
 A `Union` defines a list of possible types; similar to interfaces, whenever the
 type system claims a union will be returned, one of the possible types will be
@@ -775,8 +775,8 @@ type Person {
 }
 ```
 
-Valid operations must supply a selection of fields for any field that returns an
-object, so this operation is not valid:
+Valid operations must supply a _selection set_ for every field of an object
+type, so this operation is not valid:
 
 ```graphql counter-example
 {
@@ -810,7 +810,7 @@ And will yield the subset of each object type queried:
 **Field Ordering**
 
 When querying an Object, the resulting mapping of fields are conceptually
-ordered in the same order in which they were encountered during execution,
+ordered in the same order in which they were encountered during _execution_,
 excluding fragments for which the type does not apply and fields or fragments
 that are skipped via `@skip` or `@include` directives. This ordering is
 correctly produced when using the {CollectFields()} algorithm.
@@ -2058,8 +2058,8 @@ directive @example on
 
 Directives can also be used to annotate the type system definition language as
 well, which can be a useful tool for supplying additional metadata in order to
-generate GraphQL execution services, produce client generated runtime code, or
-many other useful extensions of the GraphQL semantics.
+generate GraphQL services, produce client generated runtime code, or many other
+useful extensions of the GraphQL semantics.
 
 In this example, the directive `@example` annotates field and argument
 definitions:
@@ -2122,7 +2122,7 @@ directive @skip(if: Boolean!) on FIELD | FRAGMENT_SPREAD | INLINE_FRAGMENT
 ```
 
 The `@skip` _built-in directive_ may be provided for fields, fragment spreads,
-and inline fragments, and allows for conditional exclusion during execution as
+and inline fragments, and allows for conditional exclusion during _execution_ as
 described by the `if` argument.
 
 In this example `experimentalField` will only be queried if the variable
@@ -2142,7 +2142,7 @@ directive @include(if: Boolean!) on FIELD | FRAGMENT_SPREAD | INLINE_FRAGMENT
 
 The `@include` _built-in directive_ may be provided for fields, fragment
 spreads, and inline fragments, and allows for conditional inclusion during
-execution as described by the `if` argument.
+_execution_ as described by the `if` argument.
 
 In this example `experimentalField` will only be queried if the variable
 `$someTest` has the value `true`

diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md
@@ -7,7 +7,8 @@ given GraphQL schema.
 An invalid request is still technically executable, and will always produce a
 stable result as defined by the algorithms in the Execution section, however
 that result may be ambiguous, surprising, or unexpected relative to a request
-containing validation errors, so execution should only occur for valid requests.
+containing validation errors, so _execution_ should only occur for valid
+requests.
 
 Typically validation is performed in the context of a request immediately before
 execution, however a GraphQL service may execute a request without explicitly
@@ -108,7 +109,7 @@ input FindDogInput {
 
 GraphQL execution will only consider the executable definitions Operation and
 Fragment. Type system definitions and extensions are not executable, and are not
-considered during execution.
+considered during _execution_.
 
 To avoid ambiguity, a document containing {TypeSystemDefinitionOrExtension} is
 invalid for execution.
@@ -579,12 +580,12 @@ type that is either an Object, Interface or Union type.
 **Explanatory Text**
 
 If multiple field selections with the same _response name_ are encountered
-during execution, the field and arguments to execute and the resulting value
+during _execution_, the field and arguments to execute and the resulting value
 should be unambiguous. Therefore any two field selections which might both be
 encountered for the same object are only valid if they are equivalent.
 
 During execution, the simultaneous execution of fields with the same response
-name is accomplished by {CollectSubfields()}.
+name is accomplished by {CollectSubfields()} before execution.
 
 For simple hand-written GraphQL, this rule is obviously a clear developer error,
 however nested fragments can make this difficult to detect manually.