-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: V4.0_ERRATA03
-
Fix Version/s: V4.01_WD01
-
Component/s: Protocol
-
Labels:None
-
Environment:
[Proposed]
-
Proposal:
-
Resolution:
Current rules around navigation properties of keyless (abstract) entity types (including Edm.EntityType) need elaborating.
Navigation properties that are typed as Edm.EntityType or a keyless abstract entity type don't have a key, so referencing an instance of a collection valued navigation property of Edm.EntityType (or any abstract entity type that doesn't define a key) is only meaningful after casting the nav prop to a non-abstract entity type with a key.
Also, since keys uniquely identify an entity within a collection, and a containment navigation property defines an entity within a collection, it doesn't make sense to have a containment navigation property of a keyless abstract type (including Edm.EntityType) (just as it doesn't make sense to have an entity set of an abstract type). This is implied by the current rules for an entity set, but we should spell out that this also applies to containment nav props (which define implicit entity sets).
We could say that a collection + type + key uniquely identifies a resource, and require casting in such cases, but unless we have scenarios that require entity sets/containment nav props of different types with different keys then that doesn't seem worth the extra complexity.