Re: TWO PROPOSALs involving Prefer - volunteering for the army

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.

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?  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/

Received on Friday, 28 February 2014 14:30:57 UTC