Change from referenced variable's type to suitable usage in its position

Author: benjie

spec/Section 5 -- Validation.md

@@ -1306,20 +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 of the
-    referenced variable's type).
+    {variableUsage} nested within {value} will represent a runtime value
+    suitable 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. Variable
-values are handled by the rule
-[All Variable Usages Are Allowed](#sec-All-Variable-Usages-Are-Allowed).
-{ListValue} and {ObjectValue} may nest additional Input Values, some of which
-may be a {variableUsage}. Each nested {variableUsage} will be coerced during
-execution - see [Coercing Variable Values](#sec-Coercing-Variable-Values) - thus
-we assume their runtime value will coerce to the type of the referenced
-variable.
+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
+[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.
 
 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