[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:comment-tabpanel&focusedCommentId=63376#comment-63376 ] 

Ralf Handl commented on ODATA-973:
----------------------------------

I see no problems in allowing Collection(Edm.ComplexType) because each item in the collection can be annotated with its @odata.type. 

For homogenous collections we can also allow Collection(Edm.PrimitiveType) because we could have:

PropertyWithTypeDeterminedAtRuntime: [ ... ],
PropertyWithTypeDeterminedAtRuntime@odata.type: "#Collection(Edm.Double)"

This notation would also be allowed for homogenous Collection(Edm.ComplexType) as a shortcut for repeating the same type in each item.

I see no need for allowing Collection(Edm.Untyped) because the outermost JSON construct of a simple Edm.Untyped could already be an array, so the only added value would be to guarantee that the outermost construct always is an array. On the other hand: why not also allow Collection(Edm.Untyped)...

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