Editorial and eliding

Author: benjie

spec/Section 6 -- Execution.md

@@ -18,14 +18,9 @@ A GraphQL service generates a response from a request via execution.
 - {extensions} (optional): A map reserved for implementation-specific additional
   information.
 
-Given this information, the result of {ProcessRequest(schema, document,
-operationName, variableValues, initialValue)} produces the response, to be
-formatted according to the Response section below.
-
-:: Formally, _execution_ starts when executing the root selection set in
-{ExecuteRootSelectionSet()}. For convenience, this section also contains
-preliminary steps required for execution such as coercing variables or getting a
-source event stream.
+Given this information, the result of {Request(schema, document, operationName,
+variableValues, initialValue)} produces the response, to be formatted according
+to the Response section below.
 
 Implementations should not add additional properties to a _request_, which may
 conflict with future editions of the GraphQL specification. Instead,
@@ -40,34 +35,43 @@ chosen by the implementing service.
 
 ## Processing Requests
 
+<a name="#sec-Executing-Requests">
+  <!-- Legacy link, this section was previously titled "Executing Requests" -->
+</a>
+
 To process a request, the executor must have a parsed {Document} and a selected
 operation name to run if the document defines multiple operations, otherwise the
 document is expected to only contain a single operation. The result of the
-request is determined by the result of processing this operation according to
-the "Processing Operations” section below.
+request is determined by the result of performing this operation according to
+the "Performing Operations” section below.
+
+:: We define _execution_ as the process of executing the operation's _root
+selection set_ through {ExecuteRootSelectionSet()}, and hence _execution_ begins
+when {ExecuteSelectionSet()} is called for the first time in a request.
+
+Note: A subscription operation may call {ExecuteSelectionSet()} a number of
+times.
 
-:: We define _execution_ as the process of executing the operation's root
-selection set through {ExecuteSelectionSet()}, thus _execution_ begins when
-{ExecuteSelectionSet()} is called for the first time in a request. The
-{ExecuteRequest()} algorithm contains the preamble for _execution_, followed by
-the _execution_ itself.
+The {Request()} algorithm contains the preamble for execution, handling concerns
+such as determining the operation and coercing the inputs, before passing the
+request on to the relevant algorithm for the operation's type which then
+performs any other necessary preliminary steps (for example establishing the
+source event stream for subscription operations) and then initiates _execution_.
 
 Note: An error raised before _execution_ begins will typically be a _request
-error_, and once _execution_ begins will typically be a _field error_.
+error_, and once _execution_ begins will typically be an _execution error_.
 
-ProcessRequest(schema, document, operationName, variableValues, initialValue):
+Request(schema, document, operationName, variableValues, initialValue):
 
 - Let {operation} be the result of {GetOperation(document, operationName)}.
 - Let {coercedVariableValues} be the result of {CoerceVariableValues(schema,
   operation, variableValues)}.
 - If {operation} is a query operation:
-  - Return {ProcessQuery(operation, schema, coercedVariableValues,
-    initialValue)}.
+  - Return {Query(operation, schema, coercedVariableValues, initialValue)}.
 - Otherwise if {operation} is a mutation operation:
-  - Return {ProcessMutation(operation, schema, coercedVariableValues,
-    initialValue)}.
+  - Return {Mutation(operation, schema, coercedVariableValues, initialValue)}.
 - Otherwise if {operation} is a subscription operation:
-  - Return {ProcessSubscription(operation, schema, coercedVariableValues,
+  - Return {Subscription(operation, schema, coercedVariableValues,
     initialValue)}.
 
 GetOperation(document, operationName):
@@ -83,27 +87,28 @@ GetOperation(document, operationName):
 
 ### Validating Requests
 
-As explained in the Validation section, only requests which pass all validation
-rules should be processed. If validation errors are known, they should be
-reported in the list of "errors" in the response and the request must fail
-without processing.
+As explained in the Validation section, only operations from documents which
+pass all validation rules should be executed. If validation errors are known,
+they should be reported in the list of "errors" in the response and the request
+must fail without execution.
 
 Typically validation is performed in the context of a request immediately before
-processing, however a GraphQL service may execute a process without immediately
-validating it if that exact same request is known to have been validated before.
-A GraphQL service should only process requests which _at some point_ were known
-to be free of any validation errors, and have since not changed.
+processing, however a GraphQL service may process a request without immediately
+validating the document if that exact same document is known to have been
+validated before. A GraphQL service should only execute operations which _at
+some point_ were known to be free of any validation errors, and have since not
+changed.
 
-For example: the request may be validated during development, provided it does
-not later change, or a service may validate a request once and memoize the
-result to avoid validating the same request again in the future.
+For example: the document may be validated during development, provided it does
+not later change, or a service may validate a document once and memoize the
+result to avoid validating the same document again in the future.
 
 ### Coercing Variable Values
 
 If the operation has defined any variables, then the values for those variables
 need to be coerced using the input coercion rules of variable's declared type.
 If a _request error_ is encountered during input coercion of variable values,
-then the operation fails without _execution_.
+then the request fails without _execution_.
 
 CoerceVariableValues(schema, operation, variableValues):
 
@@ -138,7 +143,11 @@ CoerceVariableValues(schema, operation, variableValues):
 
 Note: This algorithm is very similar to {CoerceArgumentValues()}.
 
-## Processing Operations
+## Performing Operations
+
+<a name="#sec-Executing-Operations">
+  <!-- Legacy link, this section was previously titled "Executing Operations" -->
+</a>
 
 The type system, as described in the "Type System" section of the spec, must
 provide a query root operation type. If mutations or subscriptions are
@@ -151,9 +160,9 @@ If the operation is a query, the result of the operation is the result of
 executing the operation’s _root selection set_ with the query root operation
 type.
 
-An initial value may be provided when processing a query operation.
+An initial value may be provided when performing a query operation.
 
-ProcessQuery(query, schema, variableValues, initialValue):
+Query(query, schema, variableValues, initialValue):
 
 - Let {queryType} be the root Query type in {schema}.
 - Assert: {queryType} is an Object type.
@@ -171,7 +180,7 @@ It is expected that the top level fields in a mutation operation perform
 side-effects on the underlying data system. Serial execution of the provided
 mutations ensures against race conditions during these side-effects.
 
-ProcessMutation(mutation, schema, variableValues, initialValue):
+Mutation(mutation, schema, variableValues, initialValue):
 
 - Let {mutationType} be the root Mutation type in {schema}.
 - Assert: {mutationType} is an Object type.
@@ -183,13 +192,13 @@ ProcessMutation(mutation, schema, variableValues, initialValue):
 
 If the operation is a subscription, the result is an _event stream_ called the
 _response stream_ where each event in the event stream is the result of
-executing the operation’s root _selection set_ for each new event on an
+executing the operation’s _root selection set_ for each new event on an
 underlying _source stream_.
 
-Processing a subscription operation creates a persistent function on the service
+Performing a subscription operation creates a persistent function on the service
 that maps an underlying _source stream_ to a returned _response stream_.
 
-ProcessSubscription(subscription, schema, variableValues, initialValue):
+Subscription(subscription, schema, variableValues, initialValue):
 
 - Let {sourceStream} be the result of running
   {CreateSourceEventStream(subscription, schema, variableValues, initialValue)}.
@@ -198,9 +207,9 @@ ProcessSubscription(subscription, schema, variableValues, initialValue):
   variableValues)}.
 - Return {responseStream}.
 
-Note: In a large-scale subscription system, the {ProcessSubscription()} and
-{ProcessSubscriptionEvent()} algorithms may be run on separate services to
-maintain predictable scaling properties. See the section below on Supporting
+Note: In a large-scale subscription system, the {Subscription()} and
+{SubscriptionEvent()} algorithms may be run on separate services to maintain
+predictable scaling properties. See the section below on Supporting
 Subscriptions at Scale.
 
 As an example, consider a chat application. To subscribe to new messages posted
@@ -319,9 +328,8 @@ MapSourceToResponseEvent(sourceStream, subscription, schema, variableValues):
 
 - Let {responseStream} be a new _event stream_.
 - When {sourceStream} emits {sourceValue}:
-  - Let {response} be the result of running
-    {ProcessSubscriptionEvent(subscription, schema, variableValues,
-    sourceValue)}.
+  - Let {response} be the result of running {SubscriptionEvent(subscription,
+    schema, variableValues, sourceValue)}.
   - If internal {error} was raised:
     - Cancel {sourceStream}.
     - Complete {responseStream} with {error}.
@@ -335,21 +343,21 @@ MapSourceToResponseEvent(sourceStream, subscription, schema, variableValues):
   - Complete {responseStream} normally.
 - Return {responseStream}.
 
-Note: Since {ProcessSubscriptionEvent()} handles all _execution error_, and
-_request error_ only occur during {CreateSourceEventStream()}, the only
-remaining error condition handled from {ProcessSubscriptionEvent()} are internal
-exceptional errors not described by this specification.
+Note: Since {SubscriptionEvent()} handles all _execution error_, and _request
+error_ only occur during {CreateSourceEventStream()}, the only remaining error
+condition handled from {SubscriptionEvent()} are internal exceptional errors not
+described by this specification.
 
-ProcessSubscriptionEvent(subscription, schema, variableValues, initialValue):
+SubscriptionEvent(subscription, schema, variableValues, initialValue):
 
 - Let {subscriptionType} be the root Subscription type in {schema}.
 - Assert: {subscriptionType} is an Object type.
 - Let {rootSelectionSet} be the _root selection set_ in {subscription}.
 - Return {ExecuteRootSelectionSet(variableValues, initialValue,
   subscriptionType, rootSelectionSet, "normal")}.
 
-Note: The {ProcessSubscriptionEvent()} algorithm is intentionally similar to
-{ProcessQuery()} since this is how each event result is produced.
+Note: The {SubscriptionEvent()} algorithm is intentionally similar to {Query()}
+since this is how each event result is produced.
 
 #### Unsubscribe
 
@@ -644,7 +652,7 @@ A valid GraphQL executor can resolve the four fields in whatever order it chose
 (however of course `birthday` must be resolved before `month`, and `address`
 before `street`).
 
-When processing a mutation, the selections in the top most selection set will be
+When performing a mutation, the selections in the top most selection set will be
 executed in serial order, starting with the first appearing field textually.
 
 When executing a grouped field set serially, the executor must consider each
@@ -791,9 +799,9 @@ CoerceArgumentValues(objectType, field, variableValues):
 Any _request error_ raised as a result of input coercion during
 {CoerceArgumentValues()} should be treated instead as an _execution error_.
 
-Note: Variable values are not coerced because they are expected to be coerced
-before processing the operation in {CoerceVariableValues()}, and valid
-operations must only allow usage of variables of appropriate types.
+Note: Variable values are not coerced because they are expected to be coerced in
+{CoerceVariableValues()} before _execution_ begins, and valid operations must
+only allow usage of variables of appropriate types.
 
 ### Value Resolution