OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

We received the second public comment during CSD01 Public Review.

The below comment archived at mailing list archive URL https://lists.oasis-open.org/archives/odata-comment/201305/msg00002.html has been registered as public comment with id c201305e00002 (procedure as described at eg. https://www.oasis-open.org/committees/download.php/48109/formal-aspects-meeting-minutes-v1.html#pcnotation).

Please refer to it by citing it's mailing list archive URL or
the id:

I have also created issue ODATA-387 (https://tools.oasis-open.org/issues/browse/ODATA-387) "Replace (at least) the second example in Section 13 of the CSDL document (public comment c201305e00002)" as issue container for the processing of this comment.

As the comment seems quite judgemental to me, I tried to transcribe its main content intact but without (not) taking party. If this did not work out well, please help the non-native English speaker I am in correcting any misconception I introduced. Thank you.

PS: I hereby suggest to add this to the agenda of thursdays's call after the action item handling and before the usual processing of issues (just to document the link to the corresponding issue and for at least opening or rejecting the issue. What do you think?

All the best,

-------- Original-Nachricht --------
Betreff: 	[odata-comment] DiscontinuedProducts is a really bad example
Datum: 	Sun, 12 May 2013 23:37:22 -0400
Von: 	Ron Dagostino <rndgstn@gmail.com>
An: 	odata-comment@lists.oasis-open.org <odata-comment@lists.oasis-open.org>

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:

<EntitySet Name="Products" EntityType="Self.Product"/>
<EntitySet Name="DiscontinuedProducts" EntityType="Self.Product"/>


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
  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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]