Clause 4 Clarify meaning of resource path conventions for entity container children. Recast clause 4 around 4 major sections 1) Well-known URLs (clause 3, 4.1 and 4.2) Service document Clarify that this URL is the URI of the service's EntityContainer Clarify that the services EntityContainer is the service document and is the service root. Pick a term: service document or service root: It is confusing to use both. Metadata document possible to also make a metadata attribute of the service document clarify that $metadata addresses the metadata document that contains the declarations that define the service's entity model. clarify requirement to expose the metadata document. Batch endpoint. possible to also make a metadata attribute of the service document clarify requirement to support a Batch service 2) Canonical URLs (clause 4.3) Clarify that the requirements of this section are normative if Canonical URLs are supported. Section 4.3.1 1st paragraph doesn't parse. As stated elsewhere, all entities must be belong to a singleton or entity set. So, not clear what the canonical path of a non-contained entity is. I am guessing that the text is meant to specify an implied entity set in the services entity container for all entities for which the entity set has not been explicitly declared. But... this text needs to be clarified. All references to entity set need to also be to singletons. Or maybe better.... define singletons as a special case of entity set where the max cardinality is 1. Consolidate references to keys to a single section defining keys both as URL segments or as parenthesized values. Define the pitfalls of the segment formulation there. 3) Composable URLs (clauses 4.4 - 4.10 Clause 4.4 should be rephrased. OData does not directly reference the references (associations in the UML sense) between entities. Rather it references association ends (the Navigation Properties and depending on operation, there are side-affects on the association. Two concepts: 1) The value of an association end (i.e. Navigation Property) is either a reference to or by-value copy of the related element. 2) The association itself is not a directly addressable model element in OData. OData does not support UML Association Classes. Navigation Properties are essentially association ends that are owned by the referencing type. (In the UML sense.) The opposite end is owned by the association in the case of no Partner specification. Otherwise it is owned by the related type. In either case, the UML association can be deleted. In the second, the partner is also set to null. 4) Operations on URLs (4.11 - 4.16)