Editorial: fixing a number of small issues

spec/Section 5 -- Validation.md

@@ -19,7 +19,7 @@ or development-time tool should report validation errors and not allow the
 formulation or execution of requests known to be invalid at that given point in
 time.
 
-**Type system evolution**
+**Type System Evolution**
 
 As GraphQL type system schema evolves over time by adding new types and new
 fields, it is possible that a request which was previously valid could later
@@ -556,8 +556,8 @@ fragment safeDifferingArgs on Pet {
 ```
 
 However, the field responses must be shapes which can be merged. For example,
-scalar values must not differ. In this example, `someValue` might be a `String`
-or an `Int`:
+leaf types must not differ. In this example, `someValue` might be a `String` or
+an `Int`:
 
 ```graphql counter-example
 fragment conflictingDifferingResponses on Pet {
@@ -1093,7 +1093,7 @@ fragment ownerFragment on Human {
 }
 ```
 
-#### Fragment spread is possible
+#### Fragment Spread is Possible
 
 **Formal Specification**
 
@@ -1118,7 +1118,7 @@ type matches the type condition. They also are spread within the context of a
 parent type. A fragment spread is only valid if its type condition could ever
 apply within the parent type.
 
-##### Object Spreads In Object Scope
+##### Object Spreads in Object Scope
 
 In the scope of an object type, the only valid object type fragment spread is
 one that applies to the same type that is in scope.
@@ -1181,7 +1181,7 @@ that if one inspected the contents of the {CatOrDogNameFragment} you could note
 that no valid results would ever be returned. However we do not specify this as
 invalid because we only consider the fragment declaration, not its body.
 
-##### Object Spreads In Abstract Scope
+##### Object Spreads in Abstract Scope
 
 Union or interface spreads can be used within the context of an object type
 fragment, but only if the object type is one of the possible types of that
@@ -1971,7 +1971,7 @@ query listToNonNullList($booleanList: [Boolean]) {
 This would fail validation because a `[T]` cannot be passed to a `[T]!`.
 Similarly a `[T]` cannot be passed to a `[T!]`.
 
-**Allowing optional variables when default values exist**
+**Allowing Optional Variables when Default Values Exist**
 
 A notable exception to typical variable type compatibility is allowing a
 variable definition with a nullable type to be provided to a non-null location

spec/Section 7 -- Response.md

@@ -66,7 +66,7 @@ If the `data` entry in the response is present (including if it is the value
 {null}), the `errors` entry must be present if and only if one or more _field
 error_ was raised during execution.
 
-**Request errors**
+**Request Errors**
 
 :: A _request error_ is an error raised during a _request_ which results in no
 response data. Typically raised before execution begins, a request error may
@@ -79,7 +79,7 @@ If a request error is raised, the `data` entry in the response must not be
 present, the `errors` entry must include the error, and request execution should
 be halted.
 
-**Field errors**
+**Field Errors**
 
 :: A _field error_ is an error raised during the execution of a particular field
 which results in partial response data. This may occur due to an internal error
@@ -92,7 +92,7 @@ is produced (see [Handling Field Errors](#sec-Handling-Field-Errors)). The
 `data` entry in the response must be present. The `errors` entry should include
 this error.
 
-**Error result format**
+**Error Result Format**
 
 Every error must contain an entry with the key `message` with a string
 description of the error intended for the developer as a guide to understand and