response and validation

Author: twof

spec/Section 5 -- Validation.md

@@ -584,6 +584,27 @@ fragment conflictingDifferingResponses on Pet {
 }
 ```
 
+### Client Controlled Nullability Designator List Dimensions
+
+**Formal Specification**
+
+* For each {field} in the document
+  * Let {fieldDef} be the definition of {field}
+  * Let {fieldType} be the type of {fieldDef}
+  * Let {requiredStatus} be the required status of {field}
+  * Let {designatorDepth} be the number of square bracket pairs in {requiredStatus}
+  * Let {typeDepth} be the number of list dimensions in {fieldType}
+  * If {typeDepth} equals {designatorDepth} return true
+  * Otherwise return false
+
+**Explanatory Text**
+
+List fields can be marked with nullability designators that look like `[?]!` to indicate the 
+nullability of the list's elements and the nullability of the list itself. For multi-dimensional
+lists, the designator would look something like `[[[!]?]]!`. The number of dimensions of the 
+designator are required to match the number of dimensions of the field's type. If the two do not 
+match then a validation error is thrown.
+
 ### Leaf Field Selections
 
 **Formal Specification**

spec/Section 7 -- Response.md

@@ -162,7 +162,7 @@ The response might look like:
 ```
 
 If the field which experienced an error was declared as `Non-Null` or marked
-`Non-Null` in the query document, the `null` result will bubble up to the 
+`Non-Null` in the query document, the `null` result will propagate to the 
 next nullable field. In that case, the `path` for the error should include
 the full path to the result field where the error was raised, even if that
 field is not present in the response.