Re: TWO PROPOSALs involving Prefer - volunteering for the army

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


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. 

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