Don't need TargetId in a deleted link for a to 0..1 relationship

Note: in OData 807 we added to errata 2 that clients should not expect targetid for deleted links for to 0..1 relationships. This allows 4.01 services to omit that information:

The JSON format spec provides specific ruled about when deleted links must be rendered:

Delta responses MUST contain a deleted-link object for each deleted link that corresponds to a $expand path in the initial request, unless either of the following is true:
• The source or target entity has been deleted
• The maximum cardinality of the related entity is one and there is a subsequent link object that specifies the same source and relationship.

This makes sense, because with a single valued navigation property, the source and the relationship in the required link object uniquely identify the navigation property that is having it’s value replaced.

There is a similar case of when a single-valued navigation property has it’s link removed. In that case, the only data needed to identify the link that should be removed is the source and the relationship.

Today, however, the spec says that the target for the link being removed must also be provided:

The deleted-link object MUST include the following properties, regardless of the specified odata.metadata value
• odata.context – the context URL fragment MUST be #

is the entity set containing the source entity
• source – The id of the entity from which the relationship is defined, which may be absolute or relative
• relationship – The name of the relationship property on the parent object
• target – The id of the related entity, which may be absolute or relative

The requirement to include the target in this scenario raises the complexity and cost for the service to do “field level” tracking as this kind of relationship is typically implemented with a foreign key column.