- From: John Arwe <johnarwe@us.ibm.com>
- Date: Fri, 10 Oct 2014 09:23:02 -0400
- To: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
- Message-ID: <OF8F898F59.44B8CF96-ON85257D6D.00461EF4-85257D6D.0049859F@us.ibm.com>
> 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
Received on Friday, 10 October 2014 13:24:21 UTC