Re: Proposals for PUT ignoring triples ACTION-93

 After some discussion at the October 7th WG meeting [1] and
Pierre-Antoine's email/proposal [2], I've decided to change my original
proposal [3] on this subject.

I've outlined some of the sections in question and provided some early
proposals on how to resolve.  I wasn't so concerned about getting the exact
specification text right but getting it going in the right direction,
leaving it to the editors to get it in shape if accepted.

Existing text:
[[
4.5.1 If HTTP PUT is performed on an existing resource, LDPR servers must
replace the entire persistent state of the identified resource with the
entity representation in the body of the request. LDPR servers may ignore
server managed properties such as dcterms:modified and dcterms:creator if
they are not under client control. Any LDPR servers that wish to support a
more sophisticated merge of data provided by the client with existing state
stored on the server for a resource must use HTTP PATCH, not HTTP PUT.
]]

Proposed change:
Change (change accepted from performed):
[[
4.5.1 If HTTP PUT is accepted on an existing resource....
]]
Additional clause:
[[
4.5.1.1 LDPR servers MUST inform clients when some of the triples the
client provided attempt to modify triples that the server doesn't allow
modifying and the server MUST provide a 4xx range status code (typically
409 Conflict) and SHOULD provide a message in the 4xx
response body that provides details about which triples could not be
persisted [[HTTP11]]
]]

Justification:
This is about "server-managed properties" and not about "unknown content"
(which is covered below).  It seems quite reasonable that these "hands off"
triples are not under the control of a client.  So the client fetches these
a resource, has no need to modify any of the SMPs, and then PUTs back what
it only cares to change.  If a client wrongfully attempts to modify the
value of a SMP, the server can/will reject the request and provide such a
response.


Existing text:
[[
4.5.4 LDPR clients should assume that an LDPR server could discard triples
whose predicates the server does not recognize or otherwise chooses not to
persist. In other words, LDPR servers may restrict themselves to a known
set of predicates, but LDPR clients must not restrict themselves to a known
set of predicates when their intent is to perform a later HTTP PUT to
update the resource.
]]

Proposed change:
[[
4.5.4 LDPR servers MUST NOT discard triples the server does not recognize
or otherwise chooses not to persist. If an LDPR server is unable to persist
any triples, it MUST respond with an appropriate 4xx range status code
[[HTTP11]].  LDPR servers SHOULD provide a message in the 4xx response body
that provides details about which triples could not be persisted.

The format of the 4xx response body is left open to the server to define.
]]

Justification:
See discussion that caused
http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_8

Extensions to LDP or future versions could provide a standard response body
or a way for a client to learn about which properties a server can't
persist.


[1] - http://www.w3.org/2013/meeting/ldp/2013-10-07
[2] - http://lists.w3.org/Archives/Public/public-ldp-wg/2013Oct/0038.html
[3] - http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0051.html

- Steve Speicher


On Tue, Sep 17, 2013 at 4:42 PM, Steve Speicher <sspeiche@gmail.com> wrote:

> Hi,
>
> I've outlined some of the sections in question and provided some early
> proposals on how to resolve.  I wasn't so concerned about getting the exact
> specification text right but getting it going in the right direction,
> leaving it to the editors to get it in shape if accepted.
>
> Existing text:
>
> [[
> 4.5.1 If HTTP PUT is performed on an existing resource, LDPR servers must
> replace the entire persistent state of the identified resource with the
> entity representation in the body of the request. LDPR servers may ignore
> server managed properties such as dcterms:modified and dcterms:creator if
> they are not under client control. Any LDPR servers that wish to support a
> more sophisticated merge of data provided by the client with existing state
> stored on the server for a resource must use HTTP PATCH, not HTTP PUT.
> ]]
>
> Proposed change:
>
> Additional clause:
> [[
> 4.5.1.1 LDPR servers MAY inform clients that some of the triples they
> provided were ignored by using a success (2xx range) status code including
> the HTTP response header Warning with descriptive text.
>
> Servers always have the options to provide additional details within the
> HTTP entity body of the response [[HTTP11]]
> ]]
>
>
> Justification:
> This is about "server-managed properties" and not about "unknown content"
> (which is covered below).  It seems quite reasonable that these "hands off"
> triples are not under the control of a client.  There could be some server
> implementations where they do absolutely no checking, for example a client
> could make an immediate change and set the dcterms:modified value to be a
> date from the early 1970s.
> If this were an error case, a client would need to rebuild the request by
> learning about this server-managed properties and remove those triples from
> the request's entity body.
> When the server ignores these triples provided in the request entity body,
> it could be useful to provide a Warning header such as:
>   HTTP/1.1 204 No content
>   ETag: "ABC"
>   Warning: LDP server ignored some server-managed properties
>
> Extensions to LDP or future versions could provide a standard response
> body or a way for a client to learn about which properties are
> server-managed.
>
>
> Existing text:
>
> [[
> 4.5.4 LDPR clients should assume that an LDPR server could discard triples
> whose predicates the server does not recognize or otherwise chooses not to
> persist. In other words, LDPR servers may restrict themselves to a known
> set of predicates, but LDPR clients must not restrict themselves to a known
> set of predicates when their intent is to perform a later HTTP PUT to
> update the resource.
> ]]
>
>
> Proposed change:
>
> [[
> 4.5.4 LDPR servers MUST NOT discard triples the server does not recognize
> or otherwise chooses not to persist. If an LDPR server is unable to persist
> any triples, it MUST respond with an appropriate 4xx range status code
> [[HTTP11]].  LDPR servers MAY provide a message in the 4xx
>
> response body that provides details about which triples could not be
> persisted.
>
> The format of the 4xx response body is left open to the server to define.
>
> ]]
>
> Justification:
> See discussion that caused
> http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_8
> Extensions to LDP or future versions could provide a standard response
> body or a way for a client to learn about which properties a server can't
> persist.
>
> - Steve Speicher
>