Major Relationships are expressed in CSDL as binary associations with association sets; navigation properties reference these associations and describe target and source "ends" of these associations.
The requirement of defining binary associations for each relationship makes the CSDL more verbose, harder to read, and moves the information that is interesting about the navigation property out of line.
A simpler way to express navigation properties is summarized in the following presentation, presented at the first OData TC Meeting in July:
https://www.oasis-open.org/apps/org/workgroup/odata/download.php/46576/Association%20Simplification.pptx.
A complete proposal would be the application of these concepts to [OData-CSDL].
As we are now allowing cross-service navigation, do we also want to allow function imports to return entities from a different service? They also have an EntitySet attribute which is currently restricted to SimpleIdentifier.
We could generalize this by also allowing the qualified form possible for NavigationPropertyBinding.
Which raises the question whether we should keep the SimpleIdentifier shorthand for referring to sets in the current entity container, for compatibility. And whether to allow it for NavigationPropertyBinding for consistency.
Section 7.3; example should show "Partner" attribute. This is true in other examples as well.
Section 7.3.3, Nullable attribute. Should this be required to be false for collection valued navigation properties? I.e., the collection must exist, even if it is empty.
Section 7.3.5, If a navigation property navigates between entity types in the same entityset, it's not true containment. Containment is when each parent conceptually defines a separate entityset for its contained children.
Section 11.3, I don't know that I would specify multiple navigationpropertybindings for the same navigation property; there's not much value. If there may be more than one I would just omit it.
Section 11.4, edm:Entity Element. Does it make sense to support inheritance here, or should we say the property must be of the specified type? I suppose it's fine to make it derived, so the same model could be used to represent different schemas, some that use derived types, I just hadn't really thought about the case before.
Need to update core part I in two places; Section 3, Data Model talks about "association types" as being structural types, and section 10.4.1.1, "Entity Set Path Expressions" talks about deducing entitysets by backing association sets (needs to be updated to describe navigationpropertybindings).
Added application of resolution for [CORE]
The 2012-11-16 version of the document proposes four forms of stating the entity set. This is inconsistent with type usage, which always has to be consistently qualified with the schema namespace or alias name.
I suggest to simplify NavigationPropertyBinding to always require qualified names of the form
<NavigationPropertyBinding EntitySet="SchemaNamespaceOrAlias.Container.Set" .../>
i.e. with at least three name segments.