Add validation rule that operation types exist

spec/Section 3 -- Type System.md

@@ -148,12 +148,14 @@ type system where those operations begin.
 The {`query`} root operation type must be provided and must be an Object type.
 
 The {`mutation`} root operation type is optional; if it is not provided, the
-service does not support mutations. If it is provided, it must be an Object
-type.
+service does not support mutations (see
+[Operation Type Existence](#sec-Operation-Type-Existence)). If it is provided,
+it must be an Object type.
 
 Similarly, the {`subscription`} root 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.
+not provided, the service does not support subscriptions (see
+[Operation Type Existence](#sec-Operation-Type-Existence))s. If it is provided,
+it must be an Object type.
 
 The {`query`}, {`mutation`}, and {`subscription`} root types must all be
 different types if provided.

spec/Section 5 -- Validation.md

@@ -129,6 +129,46 @@ extend type Dog {
 
 ## Operations
 
+### All Operation Definitions
+
+#### Operation Type Existence
+
+**Formal Specification**
+
+- For each operation definition {operation} in the document.
+- Let {operationRootType} be the root type in {schema} corresponding to the type
+  of {operation}.
+- {operationRootType} must exist.
+
+**Explanatory Text**
+
+Each operation must reference an operation type which has a valid root type in
+the schema.
+
+For example given the following schema:
+
+```graphql example
+type Query {
+  hello: String
+}
+```
+
+The following operation is valid:
+
+```graphql example
+query helloQuery {
+  hello
+}
+```
+
+While the following operation is invalid:
+
+```graphql example
+mutation goodbyeMutation {
+  goodbye
+}
+```
+
 ### Named Operation Definitions
 
 #### Operation Name Uniqueness