RE: [odata-comment] DiscontinuedProducts is a really bad example

Hi Ron,

Thank you for the comment!

The OData Technical Committee will process this comment and we will respond back to you soon.

From: odata-comment@lists.oasis-open.org [mailto:odata-comment@lists.oasis-open.org] On Behalf Of Ron Dagostino
Sent: Montag, 13. Mai 2013 05:37
To: odata-comment@lists.oasis-open.org
Subject: [odata-comment] DiscontinuedProducts is a really bad example

Section 13 of the CSDL document gives this example:

"Other entity models may expose multiple entity sets per type. For instance, an entity model may have the following entity sets:

This is a really bad example at best. 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.

Mike Pizzo provides a better example of exposing a single type across multiple entity sets here (http://mailinglist.odata.org/scripts/wa-ODATA.exe?A2=ODATA;bc4700a0.1302). 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.

Way to go on the whole simplification of relationships and removal of Association and AssociationSet.

A clearly articulated example of unidirectional relationships along with when EntitySet.NavigationPropertyBinding and NavigationProperty.Partner are optional vs. required would be helpful. Right now they are labelled SHOULD and MAY, respectively, but there are cases where they are required (Mike's example above I believe is one of them), and it would be helpful if the docs gave good examples that fully described when these optional elements are actually required. It is also potentially confusing because the lack of a Partner attribute could be misconstrued as meaning the relationship is unidirectional. It might be best to add a "Unidirectional" attribute to the NavigationProperty element that defaults to false but must be set to true when the relationship is unidirectional -- then the lack of a Partner attribute alone cannot be misconstrued as implying a unidirectional relationship when in fact it is simply omitted because it adds no meaning in a particular context.

Ron

odata-comment message