Re: TWO PROPOSALs involving Prefer - volunteering for the army

On 28 Feb 2014, at 14:34, Sandro Hawke <sandro@w3.org> wrote:

>> 
>> Why? Because I think the client that wants to POST to an ldp:DirectContainer or an ldp:IndirectContainer will want to do a conditional POST.  Otherwise how
>> does the client know that the server has not changed the membership properties between the time it read the content and the time the POST arrived? 
>> I wonder if this has been thought through enough? It seems to suggest that an ldp:(In)directContainer should not have its etag change unless those properties 
>> change.
> 
> The Working Group has not accepted your proposal that clients MUST understand the membership triples before POSTing. I'm pretty sure many of us would formally object to such a proposal.

I disagree. this is already in the current spec. I am just making what is there a bit more explicit by
taking a admittedly extreeme example. If you want to formally object what would be your 
grounds for doing so?

Here are just some of the reasons for my position: 

=> POST in http is non idempotent. POSTing does things. And when an agent does things in a space
where there are rules. That is why one does not just POST anything anywhere. 
=> The consequences of POSTing to a all forms of LDPCs  are known to the client and explicity stated in the spec:

  6.4.3 When a successful HTTP POST request to a LDPC results in the creation of an LDPR, the LDPC must update its membership triples to reflect that addition, and the resulting membership triple must be consistent with any LDP-defined predicates it exposes. A LDP Direct Container or LDP Container's membership triples may also be modified via through other means.

There are a huge number of reference throughout the document to membership triples. You cannot really write a client that uses ldp:IndirectContainers
or ldp:DirectContainers without understanding that concept. The differences are then made clear.
The following table illustrates some differences between membership and containment triples. For details on the normative behavior, see appropriate sections below.

Completed Request	Effects
Membership	Containment
LDPR created in LDP-BC	New triple: (LDPC, ldp:contains, LDPR)	Same
LDPR created in LDP-DC	New triple links LDP-RS to created LDPR. LDP-RS URI may be same asLDP-DC	New triple: (LDPC, ldp:contains, LDPR)
LDPR created in LDPC	New triple links LDP-RS to content indicated URI	New triple: (LDPC, ldp:contains, LDPR)
LDPR is deleted	Triples may be removed	Triples are removed
LDPC is deleted	Triples and member resources may be removed	Triples of form (LDPC, ldp:contains, LDPR) and contained LDPRs may be removed

I could find more I am sure.

Henry



Social Web Architect
http://bblfish.net/