Proposals for PUT ignoring triples ACTION-93

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