I don't know. I fear that the answer is no; after a DELETE, the resource
is deleted, so by definition THAT resource doesn't have an etag anymore.
There is something with Etags here that keeps worrying me. Because of
the way that etags are distributed over an XCAP document (i.e., all
elements/resources share the same etag value), it seems that we lose
some important property for some XCAP applications.
Let's say we have an XML document that has two sub trees. In one subtree
(called <bar>) you have a flat list of properly indexed, simple
elements, like
<foo name="x">TRUE</foo>
Naturally updating this list doesn't require safe updates at all. One
could simply PUT/GET/DELETE blindly using the name attribute as
selection key.
Now let's say that the other subtree (called <baz>) is a much more
elaborate object, where safe updates are required. SOmething akin to
common policy <rules> for example.
Because of the way we have currently defined etags usage, I believe any
blind update to the <bar> subtree automatically forces also getting the
<baz> subtree, because the etags have changed.
I think this is really suboptimal, and it would be great if it could be
somehow avoided. For example, having the possibility for an application
to define etag "ranges". In the above example, there would be three
ranges defined: One for the root element of the document, second for the
bar subtree and the third for the baz tree. A change would only
propagate within a single range.