Major Section 3 currently states that an entity can be a member of at most one entity set. Given the ability to model entity type hierarchies this restriction seems rather unnatural: "Manager" is a specialization of "Employee", so it seems natural to have two entity sets "Managers" and "Employees", the former being a true subset of the latter, and a new "Manager" entity, POSTed to either set, would automatically appear in both.
Currently the only way to do that is to have an "Employees" entity set and a "Managers" function, with the drawback that the function is not advertised in the service document and thus not consumable in a hypermedia fashion.
Holding over to discuss at Zurich F2F.
proposal was:
"Remove sentence "An entity can be a member of at most one entity set." in fourth paragraph of section 3.
Servers not able to cope with this can always restrict the models they serve to only allow one "place of residence" per entity."
Consistent with offline discussion with Ralf and others, changing proposal to:
"Close without action"
Reasoning:
An OData entity is just a shadow of the "real thing" living somewhere in the domain model of an enterprise application. A "real thing" can cast multiple shadows, so it may show up in many OData services. Or multiple times in one service.
So I have NorthernCustomers(4711), SouthernCustomers(4712), EasternCustomers(4711), and WesternCustomers(4712). Each of four OData entities nicely belongs to one entity set. All of these sets use the same entity type, and that some of these entities have the same key value is all the indication a client will get that if it changes one of the four, another one will magically also change. We might give a hint by using the same edit link in entities with the same key, but probably that's not worth the trouble; let the infrastructure generate the canonical URL for each shadow.
Enter navigation properties: each of these customers belongs to a Country, and all Country entities live in a single Countries entity set. Which is not really a problem anymore: the Country navigation property in Customer and the Customers navigation property in Country just don't have a Partner attribute, and the latter either has no navigation property binding or binds to the Customers entity set where a third shadow of each "real thing" lives.
So the MEST problem seems to be solved and I think we can close the ticket without action; we have everything in place to model our situation.
OData is built around the assumption that the entity set plus the key values identify an entity within a service
On second thought I'd prefer to have "MyCustomers", "TopCustomers", "PreferredCustomers", "DelinquentCustomers", "NewCustomers" as first-class citizens directly in the service document, and entity sets are the natural construct for that.
We'd also accept POST on MyCustomers, which will automatically link the customer to the authenticated user.
Servers not being able to accept POST on multiple sets can use the Capabilities vocabulary and annotate exactly one entity set with an InsertRestriction that tells clients not to POST here, or simply only expose models with one entity set per type.
There's no need to restrict all servers.