- From: <henry.story@bblfish.net>
- Date: Fri, 28 Feb 2014 18:08:21 +0100
- To: Sandro Hawke <sandro@w3.org>
- Cc: Roger Menday <roger.menday@uk.fujitsu.com>, Linked Data Platform WG <public-ldp-wg@w3.org>
On 28 Feb 2014, at 16:32, Sandro Hawke <sandro@w3.org> wrote: > On February 28, 2014 9:42:05 AM EST, Roger Menday <roger.menday@uk.fujitsu.com> 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. >>> >>> 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? Only for Direct and Indirect Containers. >> A client will need to understand (and like) what will be created and >> how it will be linked to decide if it wants to go ahead. >> > > I'm not sure what you mean by "understand" and "like" if you don't mean the client MUST get fetch the membership configuration and MUST match a pattern hardcoded into the client software, including the predicate URI. > > I think that's overly restrictive, by quite a bit. It could be useful to prevent a class of error, I suppose, but I think it will cause more problems than it solves. > > I'm fairly sure most client implementors will ignore this rule, because it's easier on them and will probably result in fewer user complaints. If we assume that clients are going to ignore all the Direct and IndirectContainer rules, then we should not be trying to specify them. It would make the spec a lot simpler without them. If we have them then we must assume clients do not ignore them, and that means that servers can create services where they rely on the client understanding these relations. IF this takes off and it is helpful then people will rely on their clients following the protocol correctly. They will then be complaining in court if clients do ignore the rules. For example when a "ignore the rules client" just POSTs something to an auction collection, which would be correctly interpretable as binding them to selling their goods. > > - Sandro > >> Roger >> >> >>> Or is there some other kind of understanding you have in mind? >> 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 17:31:35 UTC