Re: recursive deletion (Re: Model questions)

* Roger Menday <roger.menday@uk.fujitsu.com> [2013-01-29 08:28+0000]
> > 
> > 
> > 2. When a collection is deleted are its members deleted also?
> > This is the composition vs. aggregation question.  We closed issue
> > http://www.w3.org/2012/ldp/track/issues/25 but I don't think
> > the matter is settled.
> > 
> > We agree that both composition and aggregation are needed but we
> > don't have agreement on mechanisms.  http://www.w3.org/2012/ldp/track/issues/34
> > covers a part of it.
> > 
> > There seem to be three proposals:
> > A.  Use an attribute on the collection to indicate composition or aggregation
> > B.  Use two separate classes for composition and aggregation
> > C.  Delete all members when a collection is deleted.  Use links to cover the
> > aggregation case.
> > 
> > Perhaps we need an issue to decide on the mechanism.
> > 
> > This is my assessment of the situation.  I know I don't have to say this to this
> > group, but don't be shy and send mail if you disagree
> 
> Hi Ashok, 
> 
> Thanks for your summary. You asked for opinions :) and so, I will offer you my opinion on your second question. My opinion is that recursive deletion of resources is a bad idea and we should drop it !! 
> 
> I don't see that once a resource goes out into the big wide world why it should be cut short when their creator is deleted. 
> 
> For recursive delete to work, this requires that a child resource to be kept strictly under the management of the parent. I don't think that this is way things should work, and it is definitely not the way that the web works either. It might work sometimes, but, it certainly won't be able to work all of the time. The creation semantic of LDP needs to be more flexible than that. It needs to be able to accommodate resource creation on different servers, moving resources, persistent resources, etc etc ... 

I see a tension here between a simple LDP system is attractive to hackers and one which encourages good web practice. In programming, one routinely creates lists of things and then throw them all away.

Since the web doesn't demand reference counting, following that pattern is a quite sociopathic, with 404s breaking lots of critical infrastructure. Worse, if one creates a container and some resources, deletes it, and creates another, the program may happen to re-use the names from the first resource. Now the system is not failing to provide with critical information, but actually lying.

It's hard to imagine that hackers checking out LDP will see much value if it doesn't permit them to create and delete collections, leaving no crap for them to clean up. On the other hand, it's realy really hard to imagine deployment of recursive-delete in large systems unless they impose the rule "don't delete containers".

My guess is that the best path is to offer both behaviors, document the cost of recursive delete, and expect LDP servers to honor requests to change containers to aggregators when they reallize they want to delete some list of resources when without incurring a lot of collateral damage. Sorry for upping the bar.


> Roger
> 



-- 
-ericP

Received on Tuesday, 29 January 2013 13:05:40 UTC