Editorialize change sites

I went through this editorial in two passes. One where I tuned the usage of "operation", "request", and "selection set". I hopefully made these spots slightly clearer, but I'm open to feedback. Second pass was more freeform prose edits in cases where I thought the intended ideas could have been clearer and avoid the query ambiguity in the first place.

CONTRIBUTING.md

@@ -51,7 +51,7 @@ move forward. See editor Lee Byron talk about
 
   Once a query is written, it should always mean the same thing and return the
   same shaped result. Future changes should not change the meaning of existing
-  schema or operations or in any other way cause an existing compliant GraphQL
+  schema or requests or in any other way cause an existing compliant GraphQL
   service to become non-compliant for prior versions of the spec.
 
 * **Performance is a feature**

spec/Section 1 -- Overview.md

@@ -38,30 +38,30 @@ GraphQL has a number of design principles:
 
  * **Hierarchical**: Most product development today involves the creation and
    manipulation of view hierarchies. To achieve congruence with the structure
-   of these applications, a GraphQL operation itself is structured hierarchically.
-   The operation is shaped just like the data it returns. It is a natural
-   way for clients to describe data requirements.
+   of these applications, a GraphQL request itself is structured
+   hierarchically. The request is shaped just like the data it returns. It is
+   a natural way for clients to describe data requirements.
 
  * **Product-centric**: GraphQL is unapologetically driven by the requirements
    of views and the front-end engineers that write them. GraphQL starts with
    their way of thinking and requirements and builds the language and runtime
    necessary to enable that.
 
  * **Strong-typing**: Every GraphQL service defines an application-specific
-   type system. Operations are executed within the context of that type system.
-   Given an operation, tools can ensure that the operation is both syntactically
-   correct and valid within the GraphQL type system before execution, i.e. at
+   type system. Requests are executed within the context of that type system.
+   Given an operation, tools can ensure that it is both syntactically correct
+   and valid within the GraphQL type system before execution, i.e. at
    development time, and the service can make certain guarantees about the shape
    and nature of the response.
 
- * **Client-specified operations**: Through its type system, a GraphQL service
+ * **Client-specified response**: Through its type system, a GraphQL service
    publishes the capabilities that its clients are allowed to consume. It is
    the client that is responsible for specifying exactly how it will consume
-   those published capabilities. These operations are specified at field-level
-   granularity. In the majority of client-server applications written
-   without GraphQL, the service determines the data returned in its various
-   scripted endpoints. A GraphQL operation, on the other hand, returns exactly
-   what a client asks for and no more.
+   those published capabilities. These requests are specified at field-level
+   granularity. In the majority of client-server applications written without
+   GraphQL, the service determines the data returned from from its various
+   endpoints. A GraphQL response, on the other hand, returns exactly what a
+   client asks for and no more.
 
  * **Introspective**: GraphQL is introspective. A GraphQL service's type system
    must be queryable by the GraphQL language itself, as will be described in this

spec/Section 2 -- Language.md

@@ -98,8 +98,8 @@ LineTerminator ::
   - "Carriage Return (U+000D)" "New Line (U+000A)"
 
 Like white space, line terminators are used to improve the legibility of source
-text and separate lexical tokens, any amount may appear before or after any 
-other token and have no significance to the semantic meaning of a GraphQL 
+text and separate lexical tokens, any amount may appear before or after any
+other token and have no significance to the semantic meaning of a GraphQL
 Document. Line terminators are not found within any other token.
 
 Note: Any error reporting which provides the line number in the source of the
@@ -151,7 +151,7 @@ Token ::
   - StringValue
 
 A GraphQL document is comprised of several kinds of indivisible lexical tokens
-defined here in a lexical grammar by patterns of source Unicode characters. 
+defined here in a lexical grammar by patterns of source Unicode characters.
 Lexical tokens may be separated by {Ignored} tokens.
 
 Tokens are later used as terminal symbols in GraphQL syntactic grammar rules.
@@ -251,16 +251,17 @@ However documents which do not contain {OperationDefinition} or do contain
 and validated to allow client tools to represent many GraphQL uses which may
 appear across many individual files.
 
-If a Document contains only one operation, that operation may be unnamed or
-represented in the shorthand form, which omits both the query keyword (for
-query operations only) and operation name. Otherwise, if a GraphQL Document
-contains multiple operations, each operation must be named. When submitting a
-Document with multiple operations to a GraphQL service, the name of the desired
-operation to be executed must also be provided.
+If a Document contains only one operation, that operation may be unnamed. If
+that operation is a query without variables or directives then it may also be
+represented in the shorthand form, omitting both the {`query`} keyword as well
+as the operation name. Otherwise, if a GraphQL Document contains multiple
+operations, each operation must be named. When submitting a Document with
+multiple operations to a GraphQL service, the name of the desired operation to
+be executed must also be provided.
 
-GraphQL services which only seek to provide GraphQL request execution may choose
-to only include {ExecutableDefinition} and omit the {TypeSystemDefinition} and
-{TypeSystemExtension} rules from {Definition}.
+GraphQL services which only seek to execute GraphQL requests and not construct
+new GraphQL schema may choose to only permit {ExecutableDefinition} and omit the
+{TypeSystemDefinition} and {TypeSystemExtension} rules from {Definition}.
 
 
 ## Operations
@@ -295,9 +296,9 @@ mutation {
 
 **Query shorthand**
 
-If a document contains only one operation and the operation is query operation,
-defines no variables, and contains no directives, then that operation may be
-represented in a short-hand form which omits the `query` keyword and operation
+If a document contains only one operation and that operation is a query which
+defines no variables and contains no directives then that operation may be
+represented in a short-hand form which omits the {`query`} keyword and operation
 name.
 
 For example, this unnamed query operation is written via query shorthand.
@@ -332,8 +333,8 @@ under-fetching data.
 }
 ```
 
-In this query operation, the `id`, `firstName`, and `lastName` fields form a selection
-set. Selection sets may also contain fragment references.
+In this query operation, the `id`, `firstName`, and `lastName` fields form a
+selection set. Selection sets may also contain fragment references.
 
 
 ## Fields
@@ -403,7 +404,7 @@ Fields are conceptually functions which return values, and occasionally accept
 arguments which alter their behavior. These arguments often map directly to
 function arguments within a GraphQL service's implementation.
 
-In this example, we want to fetch a specific user (requested via the `id`
+In this example, we want to query a specific user (requested via the `id`
 argument) and their profile picture of a specific `size`:
 
 ```graphql example
@@ -452,11 +453,11 @@ These two operations are semantically identical:
 
 Alias : Name :
 
-By default, the key in the response object will use the field name
-queried. However, you can define a different name by specifying an alias.
+By default, a field's response key in the response object will use that field's
+name. However, you can define a different name by specifying an alias.
 
 In this example, we can fetch two profile pictures of different sizes and ensure
-the resulting object will not have duplicate keys:
+the resulting response object will not have duplicate keys:
 
 ```graphql example
 {
@@ -482,7 +483,7 @@ Which returns the result:
 }
 ```
 
-Since the top level of an operation is a field, it also can be given an alias:
+The fields at the top level of an operation can also be given an alias:
 
 ```graphql example
 {
@@ -493,7 +494,7 @@ Since the top level of an operation is a field, it also can be given an alias:
 }
 ```
 
-Returns the result:
+Results in:
 
 ```json example
 {
@@ -504,9 +505,6 @@ Returns the result:
 }
 ```
 
-A field's response key is its alias if an alias is provided, and it is
-otherwise the field's name.
-
 
 ## Fragments
 
@@ -1094,7 +1092,9 @@ If not defined as constant (for example, in {DefaultValue}), a {Variable} can be
 supplied for an input value.
 
 Variables must be defined at the top of an operation and are in scope
-throughout the execution of that operation.
+throughout the execution of that operation. Values for those variables are
+provided to a GraphQL service as part of a request so they may be substituted
+in during execution.
 
 In this example, we want to fetch a profile picture size based on the size
 of a particular device:
@@ -1109,10 +1109,8 @@ query getZuckProfile($devicePicSize: Int) {
 }
 ```
 
-Values for those variables are provided to a GraphQL service along with a
-request so they may be substituted during execution. If providing JSON for the
-variables' values, we could run this operation and fetch profilePic of
-size `60` width:
+If providing JSON for the variables' values, we could request a `profilePic` of
+size `60`:
 
 ```json example
 {
@@ -1122,11 +1120,10 @@ size `60` width:
 
 **Variable use within Fragments**
 
-Operation variables can be used within fragments. Operation variables have global scope
-with a given operation, so a variable used within a fragment must be declared
-in any top-level operation that transitively consumes that fragment. If
-a variable is referenced in a fragment and is included by an operation that does
-not define that variable, the operation cannot be executed.
+Variables can be used within fragments. Variables have global scope with a given operation, so a variable used within a fragment must be declared in any
+top-level operation that transitively consumes that fragment. If a variable is
+referenced in a fragment and is included by an operation that does not define
+that variable, that operation is invalid (see [All Variable Uses Defined](#sec-All-Variable-Uses-Defined)).
 
 
 ## Type References
@@ -1144,9 +1141,9 @@ NonNullType :
   - NamedType !
   - ListType !
 
-GraphQL describes the types of data expected by operation variables. Input types
-may be lists of another input type, or a non-null variant of any other
-input type.
+GraphQL describes the types of data expected by arguments and variables.
+Input types may be lists of another input type, or a non-null variant of any
+other input type.
 
 **Semantics**
 
@@ -1186,8 +1183,8 @@ including or skipping a field. Directives provide this by describing additional
 Directives have a name along with a list of arguments which may accept values
 of any input type.
 
-Directives can be used to describe additional information for types, fields, fragments
-and operations.
+Directives can be used to describe additional information for types, fields,
+fragments and operations.
 
 As future versions of GraphQL adopt new configurable execution capabilities,
 they may be exposed via directives. GraphQL services and tools may also provide