Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2

Hi,

Personally I don not like Option C, as we discussed several times. 
Besides Option B FMPOV basically moves to the properties interpretation 
the problem of having two type of containers.

Therefore, I prefer Option A, but behaving recursive by default. For 
example, a valid interpretation for a hypothetical implementation could 
be something like:

     DELETE requests to LDPC remove all members (both LDPR and LDPC)
     that bellows to the container (i.e., same base URI, even URI
     templates or whatever), keeping reference to those externals
     not directly managed by the container.

I can see this working for many uses cases. So for my let's got to 
Option A amending the 3rd point, and move forward.

Kind regards,


On 26/04/13 22:58, Arnaud Le Hors wrote:
> Hi all,
>
> Last week I tried to get us to a resolution on this issue but we didn't
> quite get to it. I'd like to try again. We actually have 3 different ways
> to do so:
>
> ** Option A: Close Issue-59 per Steve's suggestion (see
> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0018.html ):
>
> 1. remove the two types of container AggregateContainer and
> CompositeContainter, leaving the only kind of container to be
> ldp:Container
>
> 2. specify that on deleting a container LDP servers MUST delete the
> container and MAY delete member resources (typically to satisfy internal
> requirements).
>
> So if I have:
>
> <>  a ldp:Container;
>     rdfs:member<a>.
>
> and I create<b>  using POST to the container, I end up with:
>
> <>  a ldp:Container;
>     rdfs:member<a>,<b>.
>
> When I delete the container, the container gets deleted, and<a>  and<b>
> MAY get deleted.
>
> 3. Defer adding an operation that let's a client request a recursive
> delete to a future version of LDP.
> -------------
>
> ** Option B: The following alternative, inspired by Henry's proposal
> around ldp:contains:
>
> 1. remove the two types of container AggregateContainer and
> CompositeContainter, leaving the only kind of container to be
> ldp:Container
>
> 2. add that on creating a new member resource using POST, LDP servers
> SHOULD add a triple a la :<>  ldp:contains<newly_created_resource>  if the
> resource will be deleted when the container is deleted. Note that this is
> in addition to adding the appropriate ldp:membershipPredicate or
> ldp:membershipPredicateInverse triple to the container representation as
> currently required.
>
> 3. specify that on deleting a container LDP servers MUST delete the
> container and member resources listed as contained via ldp:contains, and
> MAY delete other member resources (typically to satisfy internal
> requirements).
>
> So if I have:
>
> <>  a ldp:Container;
>     rdfs:member<a>.
>
> and I create<b>  using POST to the container, I end up with:
>
> <>  a ldp:Container;
>     rdfs:member<a>,<b>;
>     ldp:contains<b>.
>
> When I delete the container, both the container and<b>  get deleted.<a>
> MAY be deleted.
>
> 4. Defer adding an operation that let's a client request a recursive
> delete to a future version of LDP.
> -------------
>
> ** Option C: Leave the spec as it currently stands, keeping the two types
> of container: AggregateContainer and CompositeContainter
>
>
> Note that as it was pointed out last week, both options B&  C mean doing
> more work because each of this option raise their own set of additional
> issues we will need to resolve. Off the top of my head, this includes what
> it means to "move" a contained resource from one container to another in
> option B, and whether a container can be changed from one type to the
> other in option C.
>
> Thanks.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>

-- 
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at

Received on Monday, 29 April 2013 11:52:07 UTC