Context fragment of contained single entity

[HeikoTheissen]

Fixes #2000

[ralfhandl]

+1, only one comment

[ralfhandl]

I really think that the text will be easier if we define

• {entity-set} is the name of an entity set or path to a collection-valued containment navigation property
• {single-entity} is the name of a singleton or path to a single-valued containment navigation property

and then use these definitions in the text below

[ralfhandl]

Good so far. Only nit is that {singleton} also appears in

• section 10.8 Projected Entity
• section 10.10 Expanded Entity

and should be replaced with {single-entity}

[HeikoTheissen]

Sections 10.2, 10.3 and 10.4. form a triplet for the cases

• collection of entities
• one entity from a collection
• a singleton (entity) that is not contained in a collection. In this case, the {type-name} variant never occurs. A {/type-name} can occur, but is not mentioned in the text.

But in later sections, this triplet pattern is violated. There are no sections for "Derived Singleton", "Projected Singleton" or "Expanded Singleton". And "Operations Results" and "Delta Payload" lump all three cases together.

Consider describing the triplet as orthogonal to the other ingredients (derivation, projection, expansion, operation, delta).

Type of value	Collection of entities	Entity in collection	Singleton outside collection
Value if entity set (maybe implicit) is known	#{entity-collection}	#{entity-collection}/$entity	n/a
Value if entity set (maybe implicit) is unknown	#Collection({type-name})	#{type-name}	#{entity-singleton}
Derived/projected value	#{entity-collection}{/type-name}{select-list}	#{entity-collection}{/type-name}{select-list}/$entity	#{entity-singleton}{/type-name}{select-list}

What if the entity set of collection of derived values is not known (composable function w/o entity set path followed by a type cast segment)?

Collection({type-name}){/type-name-from-request}
Collection({type-name-from-request})

[ralfhandl]

We decided to merge sections 10.13 to 10.15 and get rid of 10.16

[HeikoTheissen]

odata-specs/odata-protocol/10 Context URL.md

Lines 473 to 477 in e28bd96

	Example ##ex: resource URL and corresponding context URL
	```
	http://host/service/Customers(1)/Addresses
	http://host/service/$metadata#Customers(1)/Addresses
	```

If there is a special context URL format for a property of a specific entity, why not also for a specific entity in its entirety?

http://host/service/Customers(1)
http://host/service/$metadata#Customers/$entity  /* context URL as specified */
http://host/service/$metadata#Customers(1) /* why not this? */

[ralfhandl]

If there is a special context URL format for a property of a specific entity, why not also for a specific entity in its entirety?

10 Context URL claims that

The context URL makes response payloads “self-contained”, allowing a recipient to retrieve metadata, resolve references, and construct canonical links omitted from response payloads in certain optimized formats.

4.5.8 Control Information: id (odata.id) requires that

The id control information MUST appear in responses if [...] any of a non-transient entity’s key fields are omitted from the response [...]

This means that a (JSON) representation of a full or projected entity has enough information to construct the canonical URL from the entity set name alone included in the context URL, whereas for properties of an entity the context URL in addition needs to include the key values. Same for "implicit contained entity sets" which also include the key values of the container(s).