Further editing

Author: benjie

spec/Section 5 -- Validation.md

@@ -1306,22 +1306,22 @@ fragment resourceFragment on Resource {
 - For each literal Input Value {value} in the document:
   - Let {type} be the type expected in the position {value} is found.
   - {value} must be coercible to {type} (with the assumption that any
-    {variableUsage} nested within {value} will represent a runtime value
-    suitable for usage in its position).
+    {variableUsage} nested within {value} will represent a runtime value valid
+    for usage in its position).
 
 **Explanatory Text**
 
 Literal values must be compatible with the type expected in the position they
 are found as per the coercion rules defined in the Type System chapter.
 
-A {ListValue} or {ObjectValue} may nest additional Input Values, some of which
-may be a {variableUsage}. The
+Note: A {ListValue} or {ObjectValue} may contain nested Input Values, some of
+which may be a variable usage. The
 [All Variable Usages Are Allowed](#sec-All-Variable-Usages-Are-Allowed)
-validation rule asserts that each {variableUsage} is of a type allowed in that
-position, and the [Coercing Variable Values](#sec-Coercing-Variable-Values)
-algorithm will ensure runtime values of these variables coerce correctly, thus
-we can assume the runtime value of each {variableUsage} will be suitable for
-usage in its position.
+validation rule ensures that each {variableUsage} is of a type allowed in its
+position. The [Coercing Variable Values](#sec-Coercing-Variable-Values)
+algorithm ensures runtime values for variables coerce correctly. Therefore we
+can assume the runtime value of each {variableUsage} is valid for usage in its
+position.
 
 The type expected in a position includes the type defined by the argument a
 value is provided for, the type defined by an input object field a value is