[ODATA-387] Replace (at least) the second example in Section 13 of the CSDL document (public comment c201305e00002) - OASIS Technical Committees Issue Tracker

Details

Type: Improvement
Status: Closed
Priority: Minor
Resolution: Fixed
Affects Version/s: V4.0_CSD01
Fix Version/s: V4.0_CSD02
Component/s: CSDL XML
Labels:
None
Environment:

[Applied]

Proposal:
Hide

Provide an example that shows BOTH the use of a navigation property binding (for the case where the target is known) and that does not (for the case where the target is not known). Clarify that the navigation property binding is used where this information is available, not excluded if it is "implicit".

Example text:

In the following example there are separate entity sets for standard customers and preferred customers, but only one entity set for orders. The entity sets for standard customers and preferred customers both have navigation property bindings to the orders entity set, but the orders entity set does not have a navigation property binding for the Customer navigation property, since it could lead to either set of customers:

<EntityContainer Name="Sales" IsDefaultEntityContainer="true">
<EntitySet Name="StandardCustomers" EntityType="Self.Customer">
<NavigationPropertyBinding Path="Orders" EntitySet="Orders"/>
</EntitySet>
<EntitySet Name="PreferredCustomer" EntityType="Self.Customer">
<NavigationPropertyBinding Path="Orders" EntitySet="Orders "/>
</EntitySet>
<EntitySet Name="Orders" EntityType="Self.Order"/>
</EntityContainer>

Also state in definition of Partner attribute for edm:NavigationProperty that:

if the identified partner navigation property is single-valued, it will lead back to the source entity from all related entities

if the identified partner navigation property is multi-valued, the source entity will be part of that collection

if no partner navigation property is specified, no assumptions can be made as to whether one of the navigation properties on the target type will lead back to the source entity.

Accepted:https://www.oasis-open.org/committees/download.php/49212/odata-meeting-37_on-20130516-minutes.html#odata-387
Show
Provide an example that shows BOTH the use of a navigation property binding (for the case where the target is known) and that does not (for the case where the target is not known). Clarify that the navigation property binding is used where this information is available, not excluded if it is "implicit". Example text: In the following example there are separate entity sets for standard customers and preferred customers, but only one entity set for orders. The entity sets for standard customers and preferred customers both have navigation property bindings to the orders entity set, but the orders entity set does not have a navigation property binding for the Customer navigation property, since it could lead to either set of customers: <EntityContainer Name="Sales" IsDefaultEntityContainer="true"> <EntitySet Name="StandardCustomers" EntityType="Self.Customer"> <NavigationPropertyBinding Path="Orders" EntitySet="Orders"/> </EntitySet> <EntitySet Name="PreferredCustomer" EntityType="Self.Customer"> <NavigationPropertyBinding Path="Orders" EntitySet="Orders "/> </EntitySet> <EntitySet Name="Orders" EntityType="Self.Order"/> </EntityContainer> Also state in definition of Partner attribute for edm:NavigationProperty that: if the identified partner navigation property is single-valued, it will lead back to the source entity from all related entities if the identified partner navigation property is multi-valued, the source entity will be part of that collection if no partner navigation property is specified, no assumptions can be made as to whether one of the navigation properties on the target type will lead back to the source entity. Accepted: https://www.oasis-open.org/committees/download.php/49212/odata-meeting-37_on-20130516-minutes.html#odata-387
Resolution:

Hide

https://www.oasis-open.org/committees/download.php/49277/odata-v4.0-wd02-part3-csdl-2013-05-21.docx

Accepted: https://www.oasis-open.org/committees/download.php/49447/odata-meeting-40_on-20130606-minutes.html#odata-387

Show
https://www.oasis-open.org/committees/download.php/49277/odata-v4.0-wd02-part3-csdl-2013-05-21.docx Accepted: https://www.oasis-open.org/committees/download.php/49447/odata-meeting-40_on-20130606-minutes.html#odata-387

Description

The public comment [c201305e00002](https://lists.oasis-open.org/archives/odata-comment/201305/msg00002.html) with title "DiscontinuedProducts is a really bad example'" challenges the second example given in the document revision of CSDL that participates in CSD01 public review as "really bad at best"(citation).

The example (as copied from the html version of the CSD01 PR document) for "Other entity models may expose multiple entity sets per type. For instance, an entity model may have the following entity sets:" goes like this:
"""
<EntitySet Name="Products" EntityType="Self.Product"/>
<EntitySet Name="DiscontinuedProducts" EntityType="Self.Product"/>
"""

The original poster (OP) further states w.r.t the current example, that: "It means a Product instance changes its entity set when it becomes discontinued, and that means any existing relationships to it become illegal. There are still Order instances that need to refer to it (assuming it was ordered before it was discontinued), but now they can't intuitively refer to it because it doesn't exist in the Products entity set anymore – it moved to the DiscontinuedProducts entity set. An Order entity would need to a DiscontinuedProduct navigation property in order to refer to it.

He then points to an example by Mike Pizzo of exposing a single type across multiple entity sets as provided to the odata.org mailing list [1](http://mailinglist.odata.org/scripts/wa-ODATA.exe?A2=ODATA;bc4700a0.1302). The commenter thinks, that "Including this example would not only provide a correct example, but it would also demonstrate a situation where the new NavigationPropertyBinding element of EntitySet is required in order to disambiguate the target entity sets of navigation properties."(citation)

For further details and possibly additional issues raised by the comment cf. [c201305e00002](https://lists.oasis-open.org/archives/odata-comment/201305/msg00002.html)

EDIT(in the light of subsequent postings to the comments mailing list in the same "thread"):

It is currently under investigation, if the following holds true:
"""
The mailing list messages as documented at [c201305e00006](https://lists.oasis-open.org/archives/odata-comment/201305/msg00006.html), amending and including also [c201305e00005](https://lists.oasis-open.org/archives/odata-comment/201305/msg00005.html), in turn amending and including also [c201305e00004](https://lists.oasis-open.org/archives/odata-comment/201305/msg00004.html) also amending and including [c201305e00002](https://lists.oasis-open.org/archives/odata-comment/201305/msg00002.html) further delivered details and suggested content for the resolution of the issue pointed out by [c201305e00002](https://lists.oasis-open.org/archives/odata-comment/201305/msg00002.html) and to be resolved by ~~ODATA-387~~.
"""

Replace (at least) the second example in Section 13 of the CSDL document (public comment c201305e00002)

Details

Description

Attachments

Activity

People

Dates