Exact meaning of EntitySetPath: same order or some order?

[HeikoTheissen]

Consider a bound operation with entity set path:

<Action Name="Act" IsBound="true" EntitySetPath="Order/Items">
  <Parameter Name="Order" Type="self.Order" />
  <ReturnType Type="self.OrderItem" />
</Action>

where Items is a containment navigation property.

Does this mean that the return value is contained in Orders('A')/Items for some key A? Or for the key of the binding parameter (Order/ID = 'A')?

In the first case, the EntitySetPath would not define an entity set. It would be analogous to a navigation property binding with target path ns.Container/Orders/Items, which is forbidden.

[ralfhandl]

My interpretation: some order, not necessarily the same. The key values then can tell whether it is the exact same entity.

[mikepizzo]

The current definition of EntitySetPath only allows navigation properties and type cast segments, which is outdated (for example, it doesn't support complex typed properties, so there is no way to traverse a navigation property on a complex type.) And, it neither makes a statement about whether the path is an instance path (like the target of a nav prop bindings) or an model path (like path in a nav prop binding). If it is an instance path, because keys are not supported, it cannot traverse collection-valued properties.

It would make the most sense to interpret EntitySetPath similar to the target in a navigation property binding.

[mikepizzo]

The interesting case is where the binding parameter is a single entity. Services may use the entity set path to say that the returned entity is in the same entity set. However, it wouldn't make sense to append a navigation property to an entity set, so in the case that there is a subsequent navigation property it is only valid to interpret it as starting with the single instance.

For the single value case, saying that the returned entity is from the same entity set is true in either case (whether it is the same instance or just another instance in the set). That is probably all we can say at this point without breaking backward compatibility.

So we could say that, for a single entity, the entity set path starts with the instance but, if the entity set path consists only of the name of the bound parameter, then it may return any entity within that entity set.

[HeikoTheissen]

It would make the most sense to interpret EntitySetPath similar to the target in a navigation property binding.

But that would rule out EntitySetPath="Order/Items", because Items is not single-valued, and navigation property binding targets can only traverse single-valued containement navigation properties.

So we could say that, for a single entity, the entity set path starts with the instance but, if the entity set path consists only of the name of the bound parameter, then it may return any entity within that entity set.

I like that. It would allow EntitySetPath="Order/Items" and mean that the result is an item from the same order. But...

However, it wouldn't make sense to append a navigation property to an entity set, so in the case that there is a subsequent navigation property it is only valid to interpret it as starting with the single instance.

This argument would also rule out EntitySetPath = "Order/Items/Subitems", because the navigation property Subitems cannot be appended to the entity set Orders(...)/Items. In other words: Only one level of containment navigation properties would be allowed.

[mikepizzo]

Note: For entitysetpath, we should allow either containment or non-contained with nav prop bindings.