Re: Proposals for PUT ignoring triples ACTION-93

Hi,

as mentionned in today's call, here is how my own implementation works (NB:
its not stricto sensu an LDP implementation, but aims at becoming one
eventually).

For "server managed properties" (SMP), the client is not allowed to modify
them. So whenever a client PUT or PATCH a resource, the server checks that
the proposed changes do not alter the values of the SMPs. If it does, the
server replies with an error. If however the client kept the SMPs as is,
its modifications are accepted, *then* the server applies its own
modifications to the server-managed properties.
My implementation replies to those successful changes with "200 Ok". I like
the idea that emerged during the call with TimBL to have another status
code for those cases where the PUT content has not been accepted as is, so
I'll probably implement that in the near future.

Example:

>>>>>>
GET /r1

<<<<<<
200 Ok
...
<> a :Thing ; rdfs:label "foo" ; dc:modified "2013-10-05T12:34:56+0200" .

>>>>>>
PUT /r1

<> a :Thing ; rdfs:label "bar" ; dc:modified "2013-10-05T12:34:56+0200" .

<<<<<<
200 Ok
...
<> a :Thing ; rdfs:label "bar" ; dc:modified "2013-10-07T17:18:19+0200" .

>>>>>>
PUT /r1

<> a :Thing ; rdfs:label "bar" ; dc:modified "2013-10-07T17:20:23+0200" .

<<<<<<
403 Forbidden
...
Can not edit property dc:modified .

    pa

PS: note that my implementation has no notion of "unknown property", as it
is able to store arbitrary triples. However, such properties could be
handled the same ways as SMPs above: the client is not able to *modify*
them, which includes adding one value when there are none...



On Mon, Sep 30, 2013 at 3:36 PM, John Arwe <johnarwe@us.ibm.com> wrote:

>  As noted during last week's call [1], this proposal appears to assume
> that both vanilla and chocolate servers behave the same.
>
> 4.5.1.1 as  MAY seems to violate the "no silent failures" principle.
>
> >   Warning: LDP server ignored some server-managed properties
> Seems to me that our example should be aspirational: *list* which property
> names were ignored.
>
> The proposal draws a distinction between server-managed and unknown; today
> the client's only way to distinguish them is to observe different behavior
> in response to requests... i.e. to probe the server.  That feels vaguely
> wrong.
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
> Tivoli OSLC Lead - Show me the Scenario
>
>