Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]

hello all.

On 2013-04-04 13:01 , "Steve Speicher" <sspeiche@gmail.com> wrote:
>Proposal:
>a) Remove the concepts of AggregateContainer and CompositeContainer.
>Leaving the only kind of container to be ldp:Container

very good idea. make container management dependent on how resources were
added to the container. if they were POSTed to it, they are contained and
get DELETEd. if they were linked, they are associated and only the link
gets DELETEd.

>b) Have DELETE on a container only delete the container itself, not
>its members.  This would include removing the membership triples.  The
>resources identified by the object of the membership triples, may or
>may not be deleted by the server.  Note: this is just like deletion of
>any other resource (container or not) where the server may decide to
>cleanup up not-linked-to resources.  There is always a chance that a
>link to the resource may exist beyond what the LDP server knows and it
>is probably the best judge of when to do some housecleaning (using
>other heuristics such as when or how often it was last accessed).

i have to repeat my argument that this creates orphans that are, from the
perspective of the service we are providing, undiscoverable after the
container has been DELETEd. not the best way to design hypermedia, imho.

>Out of scope (put on the "potential futures" list):
>c) Recursive-delete : since it seems like a key feature WG members are
>looking for is some kind of affordance of what will get deleted (or
>what has been deleted).  This starts to head down a way to describe
>what permissions are allows (access-control), which is outside of the
>scope of the 1.0 spec.

agreed that some scenarios such as access control are definitely out of
scope. but i don't think this applies to scenarios such as "DELETE what
has been POSTed" as a possible strategy we could define as our service.

cheers,

dret.

Received on Friday, 5 April 2013 01:09:19 UTC