Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: V4.0_ERRATA02
    • Fix Version/s: V4.02_WD01
    • Component/s: CSDL XML, JSON Format
    • Labels:
      None
    • Proposal:
      Hide

      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
      Show
      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

      Description

      There are scenarios where it's convenient to represent something as an array of arrays. In JSON this would look as:

      [["foo1","bar1"],["foo2","bar2"]]
      or
      [[

      {"foo":"foo1"}

      ,

      {"bar":"bar1"}

      ],[

      {"foo":"foo2"}

      ,

      {"bar":"bar2"}

      ]]

      Currently services must represent these as arrays of complex types that have array properties. In JSON, the result looks like:

      [

      {"value":["foo1","bar1"]}

      ,

      {"value":["foo2","bar2"]}

      ]
      or
      [{"value":[

      {"foo":"foo1"}

      ,

      {"bar":"bar1"}

      ]},{"value":[

      {"foo":"foo2"}

      ,

      {"bar":"bar2"}

      ]}]

      If we are trying to make JSON representation as close as possible to a custom representation we would need to support the former syntax (without the "value" objects).

      One problem with arrays of arrays in JSON is that we don't have a way to annotate the (array) items within the array. For example, we couldn't add count, nextLink, etc. for the inner arrays..

        Attachments

          Activity

            People

            • Assignee:
              mikep Michael Pizzo
              Reporter:
              mikep Michael Pizzo
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: