Assuming that the value of omitted properties is null or default values seems dangerous.

There may be multiple reasons that a service omits values; there may be permissions issues, certain properties may be expensive compute, etc.

We should say that, in the absence of $select, services may return a subset of properties defined in the $metadata. If $select is specified, each property must be returned or an error generated.

Client should never make assumptions about missing properties.

I don't want to loosen the contract that not specifying $select means "give me everything".

I do want to reduce the difference in representatino between structural and navigation properties.

Navigation properties are already omitted in JSON if their value can be calculated by the client from defaults, and we could do the same for structural properties, making minimal JSON even more minimalistic.

This ticket only affects the JSON format.

I think there's an important difference between structural and navigation properties. Today even a simple client can materialize an entity without needing to understand/generate any markup. We lose that if we require that simple client to know about metadata and default values.

If we were to do this I would want it something that the client had to opt into, separately from opting into minimal metadata (which, as the name implies, should just be "markup", not data). However, I really think the bits we'd be saving are unlikely to be worth the added complexity of adding another preference or format parameter – the format parameters for json are already complex enough, and asking for different combinations doesn't scale well as the matrix of options expands.

Ok, I see your point, proposal adapted.

Added restriction that service MUST include key properties

Accepted on 2013-06-20