Spec edits to reduce "query ambiguity"

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 queries or in any other way cause an existing compliant GraphQL
+  schema or operations 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**

README.md

@@ -208,7 +208,7 @@ type Droid implements Character {
 We're missing one last piece: an entry point into the type system.
 
 When we define a schema, we define an object type that is the basis for all
-queries. The name of this type is `Query` by convention, and it describes
+query operations. The name of this type is `Query` by convention, and it describes
 our public, top-level API. Our `Query` type for this example will look like
 this:
 

spec/Section 1 -- Overview.md

@@ -26,7 +26,7 @@ Which produces the resulting data (in JSON):
 ```
 
 GraphQL is not a programming language capable of arbitrary computation, but is
-instead a language used to query application services that have
+instead a language used to make requests to application services that have
 capabilities defined in this specification. GraphQL does not mandate a
 particular programming language or storage system for application services that
 implement it. Instead, application services take their capabilities and map them
@@ -38,8 +38,8 @@ 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 query itself is structured hierarchically.
-   The query is shaped just like the data it returns. It is a natural
+   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.
 
  * **Product-centric**: GraphQL is unapologetically driven by the requirements
@@ -48,20 +48,20 @@ GraphQL has a number of design principles:
    necessary to enable that.
 
  * **Strong-typing**: Every GraphQL service defines an application-specific
-   type system. Queries are executed within the context of that type system.
-   Given a query, tools can ensure that the query is both syntactically
+   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
    development time, and the service can make certain guarantees about the shape
    and nature of the response.
 
- * **Client-specified queries**: Through its type system, a GraphQL service
+ * **Client-specified operations**: 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 queries are specified at field-level
+   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 query, on the other hand, returns exactly what
-   a client asks for and no more.
+   scripted endpoints. A GraphQL operation, 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

@@ -3,7 +3,7 @@
 Clients use the GraphQL query language to make requests to a GraphQL service.
 We refer to these request sources as documents. A document may contain
 operations (queries, mutations, and subscriptions) as well as fragments, a
-common unit of composition allowing for query reuse.
+common unit of composition allowing for data requirement reuse.
 
 A GraphQL document is defined as a syntactic grammar where terminal symbols are
 tokens (indivisible lexical units). These tokens are defined in a lexical
@@ -252,13 +252,13 @@ 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 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.
+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.
 
-GraphQL services which only seek to provide GraphQL query execution may choose
+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}.
 
@@ -295,9 +295,10 @@ mutation {
 
 **Query shorthand**
 
-If a document contains only one query operation, and that query defines no
-variables and contains no directives, that operation may be represented in a
-short-hand form which omits the query keyword and query name.
+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
+name.
 
 For example, this unnamed query operation is written via query shorthand.
 
@@ -331,7 +332,7 @@ under-fetching data.
 }
 ```
 
-In this query, the `id`, `firstName`, and `lastName` fields form a selection
+In this query operation, the `id`, `firstName`, and `lastName` fields form a selection
 set. Selection sets may also contain fragment references.
 
 
@@ -402,7 +403,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 query a specific user (requested via the `id`
+In this example, we want to fetch a specific user (requested via the `id`
 argument) and their profile picture of a specific `size`:
 
 ```graphql example
@@ -432,7 +433,7 @@ Many arguments can exist for a given field:
 Arguments may be provided in any syntactic order and maintain identical
 semantic meaning.
 
-These two queries are semantically identical:
+These two operations are semantically identical:
 
 ```graphql example
 {
@@ -481,7 +482,7 @@ Which returns the result:
 }
 ```
 
-Since the top level of a query is a field, it also can be given an alias:
+Since the top level of an operation is a field, it also can be given an alias:
 
 ```graphql example
 {
@@ -543,7 +544,7 @@ query noFragments {
 ```
 
 The repeated fields could be extracted into a fragment and composed by
-a parent fragment or query.
+a parent fragment or operation.
 
 ```graphql example
 query withFragments {
@@ -564,8 +565,8 @@ fragment friendFields on User {
 }
 ```
 
-Fragments are consumed by using the spread operator (`...`). All fields selected
-by the fragment will be added to the query field selection at the same level
+Fragments are consumed by using the spread operator (`...`). All fields
+selected by the fragment will be added to the field selection at the same level
 as the fragment invocation. This happens through multiple levels of fragment
 spreads.
 
@@ -594,7 +595,7 @@ fragment standardProfilePic on User {
 }
 ```
 
-The queries `noFragments`, `withFragments`, and `withNestedFragments` all
+The operations `noFragments`, `withFragments`, and `withNestedFragments` all
 produce the same response object.
 
 
@@ -613,7 +614,7 @@ Fragments can be specified on object types, interfaces, and unions.
 Selections within fragments only return values when the concrete type of the object
 it is operating on matches the type of the fragment.
 
-For example in this query on the Facebook data model:
+For example in this operation using the Facebook data model:
 
 ```graphql example
 query FragmentTyping {
@@ -1046,7 +1047,7 @@ literal representation of input objects as "object literals."
 Input object fields may be provided in any syntactic order and maintain
 identical semantic meaning.
 
-These two queries are semantically identical:
+These two operations are semantically identical:
 
 ```graphql example
 {
@@ -1110,7 +1111,7 @@ 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 query and request profilePic of
+variables' values, we could run this operation and fetch profilePic of
 size `60` width:
 
 ```json example
@@ -1121,7 +1122,7 @@ size `60` width:
 
 **Variable use within Fragments**
 
-Query variables can be used within fragments. Query variables have global scope
+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
@@ -1143,7 +1144,7 @@ NonNullType :
   - NamedType !
   - ListType !
 
-GraphQL describes the types of data expected by query variables. Input types
+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.