Re: TWO PROPOSALs involving Prefer - volunteering for the army

On February 28, 2014 12:08:21 PM EST, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote:
>
>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.
>

Sure.

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

I'm only saying they will ignore the rules if the rules are excessive.  


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

I think this reflects an unrealistic, perhaps idealistic, expectation of how these systems will work.   

I'll back off the suggestion I would formally object, mostly because I have no plans to use direct or indirect containers.   It seems like a bad idea, but if everyone who uses these containers wants to say clients MUST recognize the member predicate, I won't stand in the way.

    - Sandro

>
>> 
>>    - 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 Saturday, 1 March 2014 01:31:57 UTC