Support Arrays of Arrays

Proposal: 1) Defer supporting collections of collections until we work through semantics. 2) When we do support collections of collections ... of types, represent in CSDL as Type="Collection(Collection(...myType.Foo...))" 3) In JSON, always represent the inner collections as an object with a "value" property that is the array containing the collection members. In this way we have a consistent representation that supports annotating the inner members. 4) arrays of arrays in JSON can still be represented as untyped or Collection(untyped). 5) Take some time to think through other ramifications (i.e., how we reference nested collections within a request). For example: a) How do we get counts on nested members? b) How do we get just nested members with more than 10 values? c) How do we apply a filter to nested members? d) How do we select a subset of properties from nested members? e) etc... Previous Proposals: 1) Don't add a formal notion of arrays of arrays to the data model (it breaks too many rules). Instead, use "Edm.Untyped" (see ODATA-881 ) or "Collection(Edm.Untyped)" (see ODATA-973 ) as a way to allow payloads that contain such structure. 2) Support a new application/json type parameter "odata.annotations" that can have values "external" or "structured". "external" is the current behavior, is the default, and is required for conformance. "structured" means that annotations on non-structured property values are represented by converting the property value to an object containing any annotations plus the property "value" containing the value for the property. If a JSON payload contains an array of non-structured values, and odata.annotations=structured is not specified, then those annotations are omitted. If the annotations are necessary for correctly interpreting the payload (for example, odata.nextLink), then the service returns an error. 3) Similar to TypeDefinition for primitive types add a CollectionTypeDefinition element with an UnderlyingType attribute and a Nullable facet that allows defining a reusable collection type. The underlying type can be any type in scope, including another CollectionTypeDefinition, as long as that doesn't introduce a cycle. If the UnderlyingType is a primitive type, other type-specific facets can be specified. JSON representation of a CollectionTypeDefinition instance is an array whose items are representations of instances of the UnderlyingType Consider using the shorter name of CollectionType which was used with similar semantics and different syntax in OData V3, https://msdn.microsoft.com/en-us/library/ee781155.aspx Consider using the TypeDefinition element for defining both faceted primitive types and collection types