Determine how we want to model EDV "delete" and how to handle history/revisions

[dlongley]

In current EDV implementations, "delete" is performed by the client by creating a tombstone (an empty document) and sending it to the server. There's still more discussion to be had around preserving resource history (e.g., whether or not all EDVs MUST support preserving history/revisions and how we may forcibly remove that history to "fully" delete a resource making it non-recoverable). It may be that a separate history API would be involved there with different capabilities to read/write required.

Note that without any sort of history preservation, having an allowed action of "delete" vs. "write" is a difference without a distinction. We should be careful not to mislead users into thinking it's safe to give someone only "write" access because then they can't delete a resource. They most certainly can -- by writing an empty resource in its place (which is effectively what tombstoning is). This should be considered when determining whether implementing a history API/feature is going to be an optional layer or a hard requirement for EDVs.

[dmitrizagidulin]

Discussed on May 27 2021 call.
Next steps: need a PR to propose deletion/tombstone syntax (to start with, see how edv-client does it).