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

Use <Property> element also for NavigationProperty

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_WD01
    • Fix Version/s: V4.0_WD01
    • Component/s: CSDL XML
    • Labels:
      None
    • Environment:

      [Closed]

    • Proposal:
      Hide

      Remove NavigationProperty.

      Property defines a relationship if and only if its Type is an entity type or a collection of an entity type, in which case it MAY have a Partner attribute.

      Rejected: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/47861/latest/odata-meeting-20_on-20130110-minutes.html

      Show
      Remove NavigationProperty. Property defines a relationship if and only if its Type is an entity type or a collection of an entity type, in which case it MAY have a Partner attribute. Rejected: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/47861/latest/odata-meeting-20_on-20130110-minutes.html

      Description

      The syntax of the Property and the NavigationProperty element is almost identical. The only difference is that the Type attribute of a Property MUST NOT specify an entity type, while the NavigationProperty MUST specify an entity type (or a collection of...).

        Attachments

          Activity

          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          I'm not in favor of making things implicit; i.e., of having to understand and look at the type of the property in order to figure out that it is a navigation property (and can be used in things like $select) versus a simple property. Since there are real differences between how and where properties versus navigation properties are used, it is simpler to make it explicit by having separate elements.

          Also, note that the partner attribute is optional for navigation properties (i.e., a property may be unidirectional).

          Show
          mikep Michael Pizzo (Inactive) added a comment - I'm not in favor of making things implicit; i.e., of having to understand and look at the type of the property in order to figure out that it is a navigation property (and can be used in things like $select) versus a simple property. Since there are real differences between how and where properties versus navigation properties are used, it is simpler to make it explicit by having separate elements. Also, note that the partner attribute is optional for navigation properties (i.e., a property may be unidirectional).
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          Although Properties and Navigation Properties share some of the same attributes (there are attributes like Partner and ContainsTarget that only apply to NavigationProperty, and facets that only apply to properties), Properties and Navigation Properties are conceptually very different. Where/how they are used in the URI and payload are different, the annotations applied to each are likely to be very different, etc.

          Rather than simplifying the model, in this case trying to use a single element to represent these two very different things obscures those differences, making the model harder to understand.

          Show
          mikep Michael Pizzo (Inactive) added a comment - Although Properties and Navigation Properties share some of the same attributes (there are attributes like Partner and ContainsTarget that only apply to NavigationProperty, and facets that only apply to properties), Properties and Navigation Properties are conceptually very different. Where/how they are used in the URI and payload are different, the annotations applied to each are likely to be very different, etc. Rather than simplifying the model, in this case trying to use a single element to represent these two very different things obscures those differences, making the model harder to understand.

            People

            • Assignee:
              handl Ralf Handl
              Reporter:
              handl Ralf Handl
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: