- From: <henry.story@bblfish.net>
- Date: Fri, 28 Feb 2014 15:51:51 +0100
- To: Sandro Hawke <sandro@w3.org>
- Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
On 28 Feb 2014, at 15:30, Sandro Hawke <sandro@w3.org> wrote: > On February 28, 2014 9:00:33 AM EST, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote: >> >> 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? > > My grounds would be that it would require clients to do things I do not believe they will do. I could be persuaded by evidence of what real clients actually do. > > Your examples are constraints on the server not the client. When I buy something from the grocer, it precipitates a whole chain of events, some of which are visible to me and some of which are not. I don't need to understand them all before I buy something. If I were required to understand them all, I probably wouldn't buy as much. I did not claim that a client MUST understand *ALL* consequences of the POST action, and neither does LDP. There are indeed an huge if not infinite number of consequences to any action. When you go to the grocers and you buy something you don't need to understand all of them, but when you sign the check you need to understand one very precise consequence: that you are binding yourself to money being deduced from your bank account and transferred to the account of the grocers. If you do not understand that, you will soon see that you ability to sign cheques will be removed from you. ( Otherwise singing cheques would have no meaning ) So LDP only requires a client to understand one consequence when POSTing to an ldp:BasicContainer, and 2 consequences when posting to an ldp:DirectContainer or an ldp:IndirectContainer ( beyond the content of the graph ). ( That is what is nice about bringing all these rules down to a ldp:bindingRule as shown at the end of http://lists.w3.org/Archives/Public/public-ldp-wg/2014Feb/0124.html ) In the case of an ldp:BasicContainer the only binding is the ldp:contains, which has very little further consequences by itself. In the case of the Direct and Indirect containers there is an aditional statement created, which is clearly specified in the spec, meaning that a client cannot ignore this. > You want every client to hard code the membership predicate it's going to find in a container and refuse to post if it's not there? Or is there some other kind of understanding you have in mind? The client needs to understand the statement that will be created on POSTing. If it does not, then it SHOULD not POST there. Now all LDP clients will understand ldp:created so that all LDP clients will have no trouble understanding the consequences of POSTing to an ldp:BasicContainer. > Steve, are you okay with that requirement on your software and the software of your customers? > > - Sandro > >> 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/ > > Social Web Architect http://bblfish.net/
Received on Friday, 28 February 2014 14:52:58 UTC