OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Michael Pizzo commented on ODATA-921:
-------------------------------------

Note wording in related ODATA-951: "Containment navigation properties define entity sets, and keyless abstract entity types cannot be used as the type of an entity set, which includes Edm.EntityType. That's rather hard to deduce from the current spec, so spell it out in section 4.5 "

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]