Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-1558

Define semantics for navigation properties of type Edm.EntityType

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: V4.01_OS
    • Fix Version/s: V4.01_ERRATA01
    • Component/s: Protocol
    • Labels:
      None
    • Proposal:
      Hide

      Clarify that, if the entity type defined for a collection-valued navigation property does not define a key (including Edm.EntityType), indexing the collection by key requires a cast segment to an entity type with a key defined, and will return the entity of that type (or subtype) with the specified key, if such an instance exists.

      Show
      Clarify that, if the entity type defined for a collection-valued navigation property does not define a key (including Edm.EntityType), indexing the collection by key requires a cast segment to an entity type with a key defined, and will return the entity of that type (or subtype) with the specified key, if such an instance exists.

      Description

      OData Common Schema Definition Language (CSDL) XML Representation Version 4.01 (oasis-open.org) defines the behavior for Edm.EntityType. It specifically disallows use of Edm.EntityType as the type of an EntitySet, because all instances within an entity set must have the same key.  However, it leaves open the ability to use Edm.EntityType as the entity type of a navigation property. And, indeed, ODATA-1552 updates the xsd to allow navigation properties of type Edm.EntityType.

      What is missing is a description of the semantics of a navigation property whose type is Edm.EntityType. Specifically, since Edm.EntityType doesn't define a key, it's not possible to index into a navigation property of type Edm.EntityType by key unless you insert a cast segment.

      This is ramification is implied by other rules (so calling it out is not a breaking change) but it should be explicitly called out so that the user doesn't have to derive the semantics from the existing rules.

      We do separately have a rule that requires a collection-valued containment navigation property define a key (and thus, Edm.EntityType cannot be used as the type of a collection-valued containment navigation property):

      "For a collection-valued containment navigation property the specified entity type MUST have a key defined."

      This is consistent with entitysets, which disallow the use of Edm.EntityType "because all entities in an entity set must have the same key fields to uniquely identify them within the set".

      Are there any other semantics of a (collection-valued) navigation property of Edm.EntityType that need to be spelled out?

      Also note that, in general, if there is no navigation property binding for a non-containment collection-valued navigation property, the key may not uniquely identify the instance. This has nothing to do with Edm.EntityType, and we may want to decide to open a separate issue to track, it just came up in scope of the discussion. 

        Attachments

          Activity

            People

            • Assignee:
              mikep Michael Pizzo (Inactive)
              Reporter:
              mikep Michael Pizzo (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: