[OASIS Issue Tracker] (ODATA-973) Should we relax prohibiting Collection(Edm.ComplexType) and Collection(Edm.Untyped)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/ODATA-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Pizzo updated ODATA-973:
--------------------------------

    Environment: [Proposed]
       Proposal: 
Allow Collection(Edm.ComplexType) and Collection(Edm.Untyped).


Agree we should support Collection(Edm.ComplexType).

We can also support Collection(Edm.Untyped) since, once you're in untyped land, you may be limited in what odata semantics you can represent.

We could support homogenous collections of primitive type, but if it's homogenous we could probably define it as such in $metadata -- seems an edge case where the service can have a property that is "an array of any single primitive type".

We could consider supporting ordered collections of primitive types, as we could then annotate as property[index]@odata.type, but that's rather cumbersome (particularly for a large array) so I'd rather wait until we see if there is a need, and consider if there is a better alternative.

> Should we relax prohibiting Collection(Edm.ComplexType) and Collection(Edm.Untyped)
> -----------------------------------------------------------------------------------
>
>                 Key: ODATA-973
>                 URL: https://issues.oasis-open.org/browse/ODATA-973
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData CSDL
>    Affects Versions: V4.0_ERRATA03
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.01_WD01
>
>
> When we introduced Edm.PrimitiveType and Edm.ComplexType, we prohibited the use of them in collection-valued properties and return types because in JSON there is no way to annotate the members of an array of primitive types.  Complex types don't have the same issue (since they are internally annotated), but IIRC we made the restriction across both primitive and complex types for consistency (and because we knew we could relax it later).
> In ODATA-881 we add support for Edm.Untyped, collections of which would naturally have the same restrictions as Edm.PrimitiveType and Edm.ComplexType (i.e., not be allowed in properties or as return type of function).
> Are we still okay with these restrictions? Should we relax these constraints for collections of complex types?  For collections of Edm.Untyped that don't contain primitives? For collections of Edm.Primitive that have "heuristically determinable" types (i.e., Boolean, string, or number)?
> Or, do we say that collections of primitive, complex, or untyped are modeled as Edm.Untyped (which could be a collection)?



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)