[OASIS Issue Tracker] (ODATA-921) Specify operations for keyless nav props

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

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

Michael Pizzo updated ODATA-921:
--------------------------------

    Proposal: 
Clarify:
-Can't have containment nav props of abstract types w/o keys (including Edm.EntityType)
-add note to url conventions: if you have a navigation property with no navigation property binding, the canonical URL (formed by appending the key of the child member to the navigation property path) may not uniquely identify a members (note implications for containment)

  was:
Clarify:
-Can't have containment nav props of abstract types w/o keys (including Edm.EntityType)
-For (non-containment) nav props to keyless entity types (including Edm.EntityType), you must cast to a concrete type (with a key) in order to reference a particular instance by key.


> Specify operations for keyless nav props
> ----------------------------------------
>
>                 Key: ODATA-921
>                 URL: https://issues.oasis-open.org/browse/ODATA-921
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>    Affects Versions: V4.0_ERRATA03
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.01_WD01
>
>
> 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.



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