[OASIS Issue Tracker] (ODATA-1059) Improve specification and use of NavigationProperties, EntitySets, and Singletons

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

George Ericson created ODATA-1059:
-------------------------------------

             Summary: Improve specification and use of NavigationProperties, EntitySets, and Singletons
                 Key: ODATA-1059
                 URL: https://issues.oasis-open.org/browse/ODATA-1059
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Improvement
          Components: ABNF Construction Rules, CSDL JSON , CSDL XML, Implementing OData
         Environment: Any
            Reporter: George Ericson
            Assignee: George Ericson


There is significant confusion over the role and semantics of Singletons and EntitySets.  For example, since Nullable is not an attribute, it is assumed that they must have a value, but implementors are also assuming that if a particular Singleton or EntitySet is not implemented, then a value need not be returned.

Observations on Singletons and EntitySets from an OData metamodel point of view:
1) A Singleton is a scalar Property with a Type that is an EntityType.
2) An EntitySet is an array Property with a Type that is an EntityType.
3) A NavigationProperty with ContainsTarget="True" is a scalar or array Property with a Type that is an EntityType.
4) A NavigationProperty with ContainsTarget="False" is an association end with a Type that is an EntityType.

The overlap of 1, 2, and 3 is a source of great confusion.  Additionally the reasons for variations in semantics of these metatypes are not clear.  (i.e. missing Nullable attribute.)

The following proposals are alternatives for simplifying the OData metamodel.

Proposal 1: 
1) Allow use of Singleton and EntitySet in the context of an EntityType or ComplexType declaration.
2) Deprecate the ContainsTarget attribute.
3) Add Nullable attribute to Singleton and EntitySet.

The advantages of Proposal 1:
1) Eliminates implied Singleton and EntitySet.  These are now first class citizens in all cases.
2) Simplifies specifications since containment NavigationProperty is eliminated.
3) Clarifies whether or not a value may be omitted.

Proposal 2:
1) Add EntityProperty, with same syntax and semantics as Property except that Type must be an EntityType.
2) Allow use of EntityProperty in the context of EntityContainer, EntityType, or ComplexType.
3) Deprecate the ContainsTarget attribute.
4) Deprecate Singleton and EntitySet
5) Modify syntax of NavigationProperty to only reference EntityProperties.

The advantages of Proposal 2:
1) Eliminates Singleton and EntitySet.  These are now first class EntityProperty elements in all cases.
2) Eliminates need for ContainsTarget attribute and therefore the concept of containment NavigationProperty.
3) Rationalizes the syntax differences between Singleton, EntitySet, and NavigationProperty around Property.
4) Simplifies semantics of NavigationProperty as an association.
5) Clarifies whether or not a value may be omitted.

Proposal 3:
1) Same as Proposal 2 except that instead of adding EntityProperty, instead extend Property to allow Type to be an EntityType.  In this case, the spec might refer to an entity property as a Property with Type that is an EntityType.
2) Allow use of Property in the context of EntityContainer, EntityType, or ComplexType declarations.
3) Deprecate the ContainsTarget attribute.
4) Deprecate Singleton and EntitySet
5) Modify syntax of NavigationProperty to only reference entity properties.

The advantages of Proposal 3:
1) Everything in Proposal 2.
2) Does not add a new metatype. 




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