Define Data Collections used in the spec

spec/Appendix A -- Notation Conventions.md

@@ -216,3 +216,38 @@ Fibonacci(number):
 Note: Algorithms described in this document are written to be easy to
 understand. Implementers are encouraged to include equivalent but optimized
 implementations.
+
+## Data Collections
+
+A data collection is a finite, iterable aggregation of elements whose iteration
+order is not necessarily stable. This specification describes the semantic
+properties of data collections using types like "list", "set" and "map". These
+describe observable data collections, such as the result of applying a grammar
+and the inputs and outputs of algorithms. They also describe unobservable data
+collections such as temporary data internal to an algorithm. Each data
+collection type defines the operations available, and whether values are unique
+or ordered.
+
+**List**
+
+:: The term _list_ describes a sequence of zero or more values, which may
+contain duplicates. Currently, all lists in this specification are ordered, but
+for clarity the term "ordered list" may be used when an order is semantically
+important.
+
+**Set**
+
+:: The term _set_ describes a collection of zero or more values, which may not
+contain duplicates. Each value is considered a "member" of the set. A set is
+unordered unless explicitly stated otherwise (as an "ordered set"). For clarity,
+the term "unordered set" may be used when the lack of an order is semantically
+important.
+
+**Map**
+
+:: The term _map_ describes a collection where each element is a pair (called an
+"entry") consisting of a key and a value. Keys are unique: no two entries with
+the same key may exist in the same map, but values may repeat. A map is
+unordered unless explicitly stated otherwise (as an "ordered map"). For clarity,
+the term "unordered map" may be used when the lack of an order is semantically
+important.

spec/GraphQL.md

@@ -92,10 +92,14 @@ Conformance requirements expressed as algorithms can be fulfilled by an
 implementation of this specification in any way as long as the perceived result
 is equivalent. Algorithms described in this document are written to be easy to
 understand. Implementers are encouraged to include equivalent but optimized
-implementations.
+implementations. Similarly, data collections such as _list_, _set_ and _map_
+also introduce conformance requirements. Implementers are free to use
+alternative data collections as long as the perceived result remains equivalent.
 
 See [Appendix A](#sec-Appendix-Notation-Conventions) for more details about the
-definition of algorithms and other notational conventions used in this document.
+definition of algorithms and other notational conventions used in this document,
+and [Appendix A: Data Collections](#sec-Data-Collections) for specifics of data
+collections and their ordering.
 
 **Non-Normative Portions**