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

Navigation Property Binding (public comment c201707e0004)

    XMLWordPrintable

    Details

    • Proposal:
      Hide

      13.4.2 Binding Target

      Clarify that a containment navigation property can only be a target if it directly or indirectly belongs to a singleton - inserted text in square brackets:

      If the target is a target path, it MUST resolve to an entity set, singleton, or
      [direct or indirect] containment navigation property [of a singleton] in scope."

      15.4 Target Path - Example 67

      Replace "MyEntitySet" with "MySingleton" in third and fourth example to avoid confusion.

      13.4.1 Binding Path and 13.4.2 Binding Target - Example 37

      Part 3) of ODATA-674 was not applied - binding path may traverse collection-valued segments, binding applies to all members. Example 37 is supposed to show this. Add missing text for Part 3) of ODATA-674 and refer to it in example 37.

      [If the path traverses collection-valued complex properties or collection-valued containment navigation properties, the binding applies to all items of these collections.]

      13.4.1 Binding Path with type-cast segment ("octopus binding") and Part 2, 4.9 Addressing a Member within an Entity Collection

      We retain "octopus binding" with the semantics that:
      1) If there is a single nav prop binding with no type, you can reference members by appending the key to the nav prop.
      2) If there is a nav prop binding with a type, you must include the type when appending the key segment to the nav prop.
      3) If you want to know if you can append the key to the nav prop, you should really be looking at IndexableByKey annotation in the capabilities vocabulary.
      4) If no binding matches an instance, it is unbound (same semantics as no navigation property binding today).

      Show
      13.4.2 Binding Target Clarify that a containment navigation property can only be a target if it directly or indirectly belongs to a singleton - inserted text in square brackets: If the target is a target path, it MUST resolve to an entity set, singleton, or [direct or indirect] containment navigation property [of a singleton] in scope." 15.4 Target Path - Example 67 Replace "MyEntitySet" with "MySingleton" in third and fourth example to avoid confusion. 13.4.1 Binding Path and 13.4.2 Binding Target - Example 37 Part 3) of ODATA-674 was not applied - binding path may traverse collection-valued segments, binding applies to all members. Example 37 is supposed to show this. Add missing text for Part 3) of ODATA-674 and refer to it in example 37. [If the path traverses collection-valued complex properties or collection-valued containment navigation properties, the binding applies to all items of these collections.] 13.4.1 Binding Path with type-cast segment ("octopus binding") and Part 2, 4.9 Addressing a Member within an Entity Collection We retain "octopus binding" with the semantics that: 1) If there is a single nav prop binding with no type, you can reference members by appending the key to the nav prop. 2) If there is a nav prop binding with a type, you must include the type when appending the key segment to the nav prop. 3) If you want to know if you can append the key to the nav prop, you should really be looking at IndexableByKey annotation in the capabilities vocabulary. 4) If no binding matches an instance, it is unbound (same semantics as no navigation property binding today).
    • Resolution:
      Hide

      https://www.oasis-open.org/committees/download.php/61369/odata-v4.01-wd03-part2-url-conventions-2017-08-10.docx

      https://www.oasis-open.org/committees/download.php/61370/odata-csdl-json-v4.01-wd02-2017-08-10.docx

      https://www.oasis-open.org/committees/download.php/61371/odata-csdl-xml-v4.01-wd03-2017-08-10.docx

      Show
      https://www.oasis-open.org/committees/download.php/61369/odata-v4.01-wd03-part2-url-conventions-2017-08-10.docx https://www.oasis-open.org/committees/download.php/61370/odata-csdl-json-v4.01-wd02-2017-08-10.docx https://www.oasis-open.org/committees/download.php/61371/odata-csdl-xml-v4.01-wd03-2017-08-10.docx

      Description

      Public Review Comment https://lists.oasis-open.org/archives/odata-comment/201707/msg00004.html

      This comment concerns navigation property bindings. There are two parts, a general issue with 4.0 and a similar issue that has been introduced with 4.01. The comment refers to:

      OData Common Schema Definition Language (CSDL) XML Representation Version 4.01
      Committee Specification Draft 02 / Public Review Draft 02

      § 8.4 says:

      > Containment navigation properties define an implicit entity set for each instance of its declaring structured
      > type

      § 13.4 says:

      > If the entity type of an entity set or singleton declares navigation properties, a navigation property binding
      > allows describing which entity set or singleton will contain the related entities

      It therefore makes sense that a Binding Target must identify a single entity set.

      My issue is that this path is allowed to be a path to any "containment navigation property in scope". Such a path only identifies an entity set uniquely in cases where the path includes a singleton. If the path includes an EntitySet then, as per 8.4, it will be pointing to a set of EntitySets, one per entity instance.

      § 15.4 contains an example that highlights the problem:

      > MySchema.MyEntityContainer/MyEntitySet/MyContainmentNavigationProperty

      This issue applies to both version 4.0 and 4.01. The resulting navigation property is only weakly bound. Anyone attempting to validate a link must exhaustively search every instance of MyEntitySet to determine the validity of the link. You also have the strange situation that a bound navigation property may link to two different entities WITH THE SAME KEY. (There is no requirement that keys are unique across entity sets.) This contravenes one of the methods of addressing entities in URLs:

      OData Version 4.01. Part 2: URL Conventions § 4.9

      > For [ ... ] collection-valued navigation properties with a NavigationPropertyBinding or ContainsTarget=true specification, members of the collection can be addressed by convention by appending the parenthesized key to the URL specifying the collection of entities

      So the above is already a problem IMO and I propose that the target paths be restricted to traversing Singletons (that is, if an entity set is specified it must be the last component of the path).

      Coming on to the new issue in 4.01...

      Version 4.01 has modified the way navigation bindings work to allow a single navigation property to be bound, simultaneously, to multiple entity sets based on the type of the target. Straight away this triggers the same issue, that bound navigation properties no longer have unique keys.

      I'm unhappy with the idea that a binding may now bind to multiple entity sets as it would involve removing the ability to append a key to uniquely identify an entity via a (bound) navigation path. It isn't clear what problem you're trying to solve here but it feels like it is best solved using multiple navigation properties rather than attempting an 'octopus binding'.

      Even if you allow a single bound navigation property to bind to multiple entity sets the new feature creates the possibility of a partially bound navigation property. If I have a navigation property called A of type Collection(TypeA) and TypeA has two sub-types, TypeB and TypeC then we can now bind any of the following:

      A
      A/TypeA
      A/TypeB
      A/TypeC

      The most specific rule applies so the last two rules override the first two but if we only bind A/TypeC then any instances of TypeB linked to A are unbound. The result is a partially bound navigation property. This could be corrected by requiring a default binding (with no type cast segment) if a type-cast binding is provided.

      Hopefully helpful.

      Steve

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: