Anomaly in get_subscriptionResults

[Tony.Rogers@ca.com]

I was just asked a question, and I think the answer implies a need for additional clarification of the spec.

If a user calls the get_subscriptionResults API, specifying a period of, say, 1 January 2004 to 1 January 2005, and a subscription filter that matches a particular business entity that changed on 1 July 2004, then we should return the current state of that business entity - I think we're all agreed on that. But if that business entity was deleted on 1 May 2005, which is AFTER the requested period, should we return the business as deleted (in other words, should we include its key in a delete key bag?)?

As far as I can see, that's what we obliged to do. For contrast, returning the last state of the business before it was deleted is misleading, and returning the state of the business as at the end of the period is explicitly excluded by the spec.

This means that the deleted bag contains not just those entities which were deleted (real or virtual) during the period specified, but ALSO those which were deleted (but only REAL deletes, not virtual ones) since.

Right?

I think we should clarify this in the spec, because it's an anomalous and perhaps unexpected result.