[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-879) Support Arrays of Arrays
[ https://issues.oasis-open.org/browse/ODATA-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Handl updated ODATA-879: ----------------------------- Proposal: Proposal: 1) Support arrays of arrays ... of types: Type="Collection(Collection(...myType.Foo...))" 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. 3) 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. Previous Proposal: 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. Alternative: - 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 was: Proposal: 1) Support arrays of arrays ... of types (Collection(Collection(...myType.Foo...))) 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. 3) 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. Previous Proposal: 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. Alternative: - 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 > Support Arrays of Arrays > ------------------------ > > Key: ODATA-879 > URL: https://issues.oasis-open.org/browse/ODATA-879 > Project: OASIS Open Data Protocol (OData) TC > Issue Type: Bug > Components: OData CSDL, OData JSON Format > Affects Versions: V4.0_ERRATA02 > Reporter: Michael Pizzo > Assignee: Michael Pizzo > Fix For: V4.01_CSD02 > > > 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.. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]