Re: Lack of server controlled property in PUT?

> 1.  4.2.4.1 says: "LDP servers may ignore server-managed properties ... 
if
> they are not under client control."

> 2.  4.2.4.3 says: "If an otherwise valid HTTP PUT request is received 
that
> attempts to change properties the server does not allow clients to 
modify,
> LDP servers must fail the request by responding with a 4xx range status
> code (typically 409 Conflict)."

The confusion seems kinda obvious: 
- we use different words (server managed, under client control, allow 
clients to modify)
- it's not clear to readers what level of exegsis [waves to Erik W] to 
apply:  whether to take that differences in wording as evidence signalling 
distinct meanings, or as two ways of saying the same thing in natural 
language.

As those in the WG will probably recall, there are (at least) the 
following classes of "server managed properties" ... and the classes can 
overlap
1: write-once (by client) ... e.g. dcterms:previousVersion
2: server supplies default:  clients can update (potentially only once), 
but server will compute a default value ... e.g. dcterms:created
3: server always computes a value ... e.g. dcterms:modified
4: read-only (by client) ... e.g. uuid, ldp:contains, membership triples 
in many implementations
4a: server rejects requests to modify
4b: server silently ignores requests to modify (accepts the request, then 
immediately restores the previous value as if a subsequent request had 
done so)

Further complicated by some people's interpretation that simply enclosing 
the value in a PUT request body constitutes "client intent to update", 
even if the value is identical to what's on the server, which others 
consider a perverse result - it means that a GET/PUT pair with no 
client-side modifications to the payload would fail if it contains 
server-managed properties, in the absence of .1
.1 was an attempt to deal with the otherwise perverse result, by 
expliciting authorizing 4b's behavior.
.3 was (in part, at least) an attempt to deal with PUTs attempting to 
update membership or containership triples, ala 4a, without having to 
remember to update .3 every time we invent some new predicate.

Strawman:
- Define "LDP managed" properties as the set of properties constrained by 
LDP ... which might devolve to using the existing terms for membership 
triples and/or containership triples.
- Define "server managed" properties as those that the server (1) computes 
or (2) treats as write once, but are not LDP-managed, whether or not they 
are ever updatable by clients. 
-- need to be careful to distinguish "client update intent" from mere 
presence in an method whose semantic is update
- .1 is unchanged
- .3 applies to containership triples, and possibly moves up to General
-- we know we have use cases to patch *membership* triples, still allowed
-- I can't think of a single case where a client is/should be allowed to 
update containership triples, regardless of the method used
- .3 add non-normative note that clients should expect the same behavior 
if they attempt to change the value of (sic - the GET/PUT case carefully 
handled) server-managed properties ... preserving the original intent of 
4a
-- optional: move to general ... same arguments would apply to patch


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead