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

Specify operations for keyless nav props

    XMLWordPrintable

    Details

    • 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:
      Hide

      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)

      Show
      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)
    • Resolution:
      Show
      https://www.oasis-open.org/apps/org/workgroup/odata/download.php/59028/odata-v4.01-wd01-part1-protocol.docx

      Description

      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.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: