[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-674) Specify navigation property binding combined with containment
[ https://issues.oasis-open.org/browse/ODATA-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Pizzo updated ODATA-674:
--------------------------------
Labels: Gap (was: Gap request_tc_discussion)
Environment: [Proposed]
Proposal:
1) Support NavigationPropertyBinding element as a child of EntityType, ComplexType or Singleton.
2) When used in a NavigationPropertyBinding within an EntityType or ComplexType, "Path" is a path starting with a property or navigation property on the type containing the NavigationPropertyBinding element, traversing zero or more containment navigation properties, complex types, or collections of complex types, and terminating on a non-containment navigation property. If the path includes a collection of complex types or a collection-valued navigation property, then the binding applies to all members of that collection. Also support cast segments as in NavigationPropertyBinding Path today.
3) Clarify in current use of NavigationPropertyBinding that Path may traverse collections of complex types, and that when traversing collections of complex types or collection-valued navigation properties, the binding applies to all members of that collection.
4) Rules 2 & 3 mean that the Path attribute has the same syntax and semantics whether the NavigationPropertyBinding is under an EntitySet, Singleton, EntityType, or a ComplexType.
5) When used in a NavigationPropertyBinding within an EntityType or ComplexType, "Target" is a path starting with a property or navigation property on the type containing the NavigationPropertyBinding element, traversing zero or more single-valued containment navigation properties or complex types, and terminating on a containment navigation property.
6) Support cast segments in the Target attribute of NavigationPropertyBindings, both in current usage and when child of an Singleton or Entity/Complex type element declaration.
7) Clarify in current usage of NavigationPropertyBinding that Target may only traverse single-valued containment navigation properties or complex types.
8) When used in a NavigationPropertyBinding within an EntitySet or Singleton, Target may identify an entity set, singleton, or containment navigation property, but when used within an EntityType or ComplexType it must terminate in a containment navigation property. This is by design and prevents type definitions from being tied to a container. All other semantics and syntax of Target are the same whether the NavigationPropertyBinding element is the child of an EntitySet, Singleton, EntityType, or ComplexType.
9) The new usage is only allowed in a 4.01 schema:
a. Can only have NavigationPropertyBinding as a child of Singleton, EntityType, or ComplexType in 4.01 responses
b. Services should only use cast segments in Target attribute in 4.01 responses
c. Services should only return navigation property bindings whose Path traverses collections of complex types in 4.01 responses
was:
Allow NavigationPropertyBinding elements in navigation properties.
-Target is always relative to the type containing the nav prop; it may traverse one or more complex types and single value containment(?) nav props and must terminate on a containment nav prop
>>what if the type containing the nav prop is a complex type, and target is another nav prop nested under a different complex type on the same parent?
-Path is always relative to the instance(s) returned by the navigation property, and may be omitted (or "*"?) if it is the instance returned by the navigation property
>>alternatively, Path is also relative to the type containing the nav prop and MUST start with the path to the nav prop on which the binding is defined
ALSO consider navpropbinding for a singleton to specify that the singleton comes from a particular entity set. This must not be returned for 4.0 clients.
Recapping the main issues:
1) What types of navigation to allow and, in particular, whether to support a semantic segment (such as "..") for "my parent".
>>We came to the conclusion that specifying backward navigation in general required that a type know the context in which it was being used, and had a bunch of other issues. So it seemed reasonable to require that there be a parent property to navigate "up".
2) We debated where to put the navigation property binding.
>>Putting it too low required "navigating up" (see issue #1). Putting it too high (basically, putting it anywhere that navigating down would traverse a collection) lost identity (you could have two paths that went through the same collection, but nothing to say that they were related to the same instance within that collection). So we were leaning toward defining it on an entity type.
There were a host of other, smaller issues, such as:
3) Do we use the existing "NavigationPropertyBinding" element or define a new "NavigationPropertyBindingPath"
>>At one point I proposed NavigationPropertyBindingPath to distinguish its relative nature from the NavigationPropertyBinding, which is always rooted in the container, and to allow us to have different attributes (i.e., if we put the element on the navigation property we didn't need the Path attribute) and different rules/semantics for those attributes. If we put the binding on the type, however, then Path and Target still make sense, with pretty much the same rules, so it's probably better to use the existing element.
4) If we put the NavigationPropertyBinding on an EntityType definition, should we also support putting it on a ComplexType definition?
>>Keeping differences between EntityType and ComplexType to a minimum seems to be a good thing, and allowing the NavigationPropertyBinding on a complex type enables an entity type to have a (presumably ordered) collection of complex types with bound navigation properties.
5) Must the target be restricted to containment navigation properties, or can it traverse a non-containment navigation property
>>In one iteration of the design (when the nav prop binding was on the navigation property) we needed a way to follow a containment relationship from a child to its containing parent. For example, to annotate the Component navigation property of an Edge as coming from the Elements collection of the parent Hierarchy we needed to traverse the Hierarchy navigation property on Edge, which was not a containment navigation property (rather, it was the *partner* to the "Edges" containment navigation property on Hierarchy.)
~~~xml
<EntityType Name="Edge">
…
<NavigationProperty Name="Hierarchy" Type="ns.Hierarchy" Partner="Edges" Nullable="false"/>
<NavigationProperty Name="Component" Type="ns.Element" Nullable="false">
<!--The Component must be an element from the Hierarchy in which this Edge is contained-->
<NavigationPropertyBinding Path="*" Target="Hierarchy/Elements"/>
<NavigationProperty/>
…
</EntityType>
~~~
However, by putting the navigation property binding on the entity type, instead of the navigation property being bound, we can move that navigation property binding to the parent (Hierarchy) type:
~~~xml
<EntityType Name="Hierarchy">
…
<NavigationProperty Name="Elements" Type="Collection(ns.Element)" Partner="Hierarchy" ContainsTarget="true"/>
<NavigationProperty Name="Edges" Type="Collection(ns.Edge)" Partner="Hierarchy" ContainsTarget="true"/>
<!--The Component of all Edges must be an Element of this Hierarchy-->
<NavigationPropertyBinding Path="Edges/Component" Target="Elements"/>
…
</EntityType>
~~~
6) What does it mean for the Path to traverse collections? We appear to support this today when we say that the Path in a NavigationPropertyBinding can traverse containment navigation properties, without specifying that those navigation properties be single-valued.
>>Presumably navigating a collection-valued navigation property in the Path means that the binding applies to all instances within the collection. Note that it does not make sense for the Target attribute, which ultimately has to identify a single collection instance.
7) If Path is able to traverse collection-valued containment navigation properties, shouldn't it also be allowed to traverse collections of complex types?
>>Presumably yes.
8) The current rules around the Target attribute says that it can traverse zero or more complex and containment navigation properties, but does not specify that the containment navigation properties must be single valued. Shouldn't it be restricted to single-value containment navigation properties?
>>Presumably yes.
9) Today the Path attribute of a NavigationPropertyBinding supports a cast segment, but the Target attribute does not. You could argue this makes sense, as each segment of the target path has to be single-valued, thus should be a specific type. However, there may be scenarios where the property could be more generically typed but the usage through the prescribed path will always be a specific type, in which case we'd need a cast segment.
>>We should probably support a cast segment in either Path or Target, asserting that the property/nav prop is of the specified type.
> Specify navigation property binding combined with containment
> -------------------------------------------------------------
>
> Key: ODATA-674
> URL: https://issues.oasis-open.org/browse/ODATA-674
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Bug
> Components: Implementing OData, OData CSDL
> Affects Versions: V4.0_OS
> Environment: [Proposed]
> Reporter: Ralf Handl
> Assignee: Michael Pizzo
> Labels: Gap
> Fix For: V4.01_CSD02
>
>
> This combination is not explicitly covered in the specification.
> There are two sides to this problem:
> - target entity sets for contained entities
> - contained entity sets as target entity sets
> Both problems can be solved by allowing <NavigationPropertyBinding> elements as children of the structured type that defines the containment navigation property.
> Example 1: navigation property of a contained entity targets a top-level entity set:
> <NavigationProperty Name="Items" Type="Collection(Model.OrderItem)" ContainsTarget="true" />
> <NavigationPropertyBinding Path="Items/Product" Target="Model.Container/Products"/>
> Example 2: assume an Order contains Items and Shipments, and an Item refers to a single Shipment of the same Order and vice versa. Using paths that start at the type defining the containment navigation property, the Target would be "Shipments" and "Items".
> <EntityType Name="Order">
> <NavigationProperty Name="Items" Type="Collection(Model.OrderItem)" ContainsTarget="true" />
> <NavigationPropertyBinding Path="Items/Shipment" Target="Shipments"/>
> <NavigationProperty Name="Shipments" Type="Collection(Model.Shipment)" ContainsTarget="true" />
> <NavigationPropertyBinding Path="Shipments/ShippedItems" Target="Items"/>
> </EntityType>
> <EntityType Name="OrderItem">
> <NavigationProperty Name="Shipment" Type="Model.Shipment" Partner="ShippedItems"/>
> </EntityType>
> <EntityType Name="Shipment">
> <NavigationProperty Name="ShippedItems" Type="Collection(Model.OrderItem)" Partner="Shipment"/>
> </EntityType>
--
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]