- Moves OperationTypeDefinition grammar rule within the subsection that defines it.

leebyron · leebyron · commit e546c74eb87b · 2023-02-09T13:33:15.000-08:00
- Rephrase root fields as "collected from the root selection set" to be clear that the special bit is the result of CollectFields and remove ambiguity around the subscriptions single field constraint.
- Fixed an inconsistency where ResolveFieldEventStream used `rootValue` instead of `initialValue` like the rest of the document.
- Some minor copy tweaks and issues caught
diff --git a/spec/Section 3 -- Type System.md b/spec/Section 3 -- Type System.md
@@ -118,8 +118,6 @@ enum Language {
 SchemaDefinition : Description? schema Directives[Const]? {
 OperationTypeDefinition\* }
 
-OperationTypeDefinition : OperationKind : NamedType
-
 :: A GraphQL service's collective type system capabilities are referred to as
 that service's _schema_. A schema is defined in terms of the types and
 directives it supports as well as the _operation type_ for each kind of
@@ -140,6 +138,8 @@ introspection system.
 
 ### Operation Types
 
+OperationTypeDefinition : OperationKind : NamedType
+
 :: A schema defines an _operation type_ for each kind of operation it supports:
 query, mutation, and subscription. This describes the type of the _root
 selection set_ for that kind of operation and by doing so determines the place
@@ -154,8 +154,8 @@ Similarly, the subscription _operation type_ is also optional; if it is not
 provided, the service does not support subscriptions. If it is provided, it must
 be an Object type.
 
-The query, mutation, and subscription _operation type_ must each be different
-types, if provided.
+Each provided query, mutation, and subscription _operation type_ must be
+different types.
 
 The fields on the query _operation type_ indicate what fields are available at
 the top level of a GraphQL query operation.
@@ -220,8 +220,8 @@ its respective _default operation type name_ and no other type uses any _default
 operation type name_.
 
 This example describes a valid complete GraphQL schema, despite not explicitly
-including a {`schema`} definition. The {"Query"} type is presumed to be the
-query _operation type_ of the schema.
+including a schema definition. The {"Query"} type is presumed to be the query
+_operation type_ of the schema.
 
 ```graphql example
 type Query {
diff --git a/spec/Section 4 -- Introspection.md b/spec/Section 4 -- Introspection.md
@@ -69,19 +69,19 @@ underscores {"\_\_"}.
 ## Type Name Introspection
 
 GraphQL supports type name introspection within any selection set in an
-operation, with the single exception of a subscription _root selection set_.
-Type name introspection is accomplished via the meta-field `__typename: String!`
-on any Object, Interface, or Union. It returns the name of the concrete Object
-type at that point during execution.
+operation, with the exception of those collected from a subscription _root
+selection set_. Type name introspection is accomplished via the meta-field
+`__typename: String!` on any Object, Interface, or Union. It returns the name of
+the concrete Object type at that point during execution.
 
 This is most often used when querying against Interface or Union types to
 identify which actual Object type of the possible types has been returned.
 
 As a meta-field, `__typename` is implicit and does not appear in the fields list
 in any defined type.
 
-Note: `__typename` may not be included as a field in a subscription _root
-selection set_.
+Note: `__typename` may not be included as a collected field from a subscription
+_root selection set_.
 
 ## Schema Introspection
 
@@ -94,7 +94,7 @@ __type(name: String!): __Type
 ```
 
 Like all meta-fields, these are implicit and do not appear in the fields list in
-the _root type_ of the query operation.
+the query _operation type_.
 
 **First Class Documentation**
 
diff --git a/spec/Section 5 -- Validation.md b/spec/Section 5 -- Validation.md
@@ -251,7 +251,7 @@ query getName {
 
 ### Subscription Operation Definitions
 
-#### Single field in the root selection set
+#### Single collected root field
 
 **Formal Specification**
 
@@ -266,7 +266,8 @@ query getName {
 
 **Explanatory Text**
 
-Subscription operations must have exactly one field in the _root selection set_.
+Subscription operations must have exactly one field collected from its _root
+selection set_.
 
 Valid examples:
 
@@ -318,20 +319,20 @@ fragment multipleSubscriptions on Subscription {
 }
 ```
 
-The single field from the _root selection set_ of a subscription must not be an
-introspection field. The following example is invalid:
+The single field collected from the _root selection set_ of a subscription must
+not be an introspection field. The following example is invalid:
 
 ```graphql counter-example
 subscription sub {
   __typename
 }
 ```
 
-Note: While each subscription must have exactly one field in the _root selection
-set_, a document may contain any number of subscription operations, each of
-which may contain different fields. When executed, a document containing
-multiple subscription operations must provide the operation name as described in
-{GetOperation()}.
+Note: While each subscription must have exactly one field collected from the
+_root selection set_, a document may contain any number of subscription
+operations, each of which may contain different fields. When executed, a
+document containing multiple subscription operations must provide the operation
+name as described in {GetOperation()}.
 
 ## Fields
 
diff --git a/spec/Section 6 -- Execution.md b/spec/Section 6 -- Execution.md
@@ -269,12 +269,13 @@ CreateSourceEventStream(subscription, schema, variableValues, initialValue):
   argumentValues)}.
 - Return {fieldStream}.
 
-ResolveFieldEventStream(subscriptionType, rootValue, fieldName, argumentValues):
+ResolveFieldEventStream(subscriptionType, initialValue, fieldName,
+argumentValues):
 
 - Let {resolver} be the internal function provided by {subscriptionType} for
   determining the resolved event stream of a subscription field named
   {fieldName}.
-- Return the result of calling {resolver}, providing {rootValue} and
+- Return the result of calling {resolver}, providing {initialValue} and
   {argumentValues}.
 
 Note: This {ResolveFieldEventStream()} algorithm is intentionally similar to
