Re: Lack of server controlled property in PUT?

Dear all,

To be more specific, in an attempt to get a response, we believe that there
is an issue that needs to be addressed:

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)."

To rephrase 1:  LDP servers MAY ignore changes to server-managed properties
that are not under client control.
To rephrase 2:  LDP servers MUST error on changes to properties that are
not under client control.

Assuming that "server-managed properties" are "properties", there is a
logical inconsistency, as far as we can tell.  We think that this must be
addressed in the specification.  (Sorry!)


Further:

3.  We assert: Given that PUT (from 4.2.4.1) replaces the entire resource,
the lack of presence of a property is an instruction to delete it.
4.  5.2.4.1 says:   "LDP servers should not allow HTTP PUT to update a
LDPC’s containment triples; if the server receives such a request, it
should respond with a 409 (Conflict) status code."

Note: 5.2.4.1 follows from 4.2.4.3, and just reinforces that clients cannot
directly modify the (server managed) containment property.

Given 3. and 4. the implication is that clients MUST send exactly the same
containment triples as the current state of the resource.

We do not think this is a reasonable requirement for large containers (or
in fact /any/ container) and makes PUT unimplementable in any practical
sense.


Further again:

Given the scoping of 1. and 2. if there are properties that are added by
the server, but are able to be modified by the client, they MUST always be
included in the representation for PUT.  For example, every update to a
container MUST include ldp:hasMemberRelation if that is able to be
specified by the client.  The non-normative note under 4.2.4.3 clarifies
that write-once properties (as hasMemberRelation might be) are NOT
considered server-managed properties, and regardless of the inconsistency
would thus not fall under the 4.2.4.1 clause.

For systems with many server-managed properties (for example, we make ALL
resources into BasicContainers) this makes for a large implementation
cost.  We can eat that cost, but we would like to discuss if it's really
necessary.


Our proposal is to clarify that *omitting* any property that is managed by
the server is acceptable, however including it with a value that is not the
same as the current state would trigger the error condition as per 4.2.4.3
/ 5.2.4.1


I would be happy to discuss on Columbus day call, and can un-regret myself
for that purpose :)

Rob


On Fri, Oct 3, 2014 at 11:39 AM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> Hi all,
>
> A quick question that we're a little puzzled over and would appreciate
> some confirmation on...
>
> In 4.2.4.1 (copied below for reference), servers must replace the entire
> state of a resource, but they may ignore server-managed properties not
> under client control, and anything more sophisticated is PATCH rather than
> PUT.
>
> Does the clause about ignoring server-managed properties include both
> presence and lack of presence?  For example, if I PUT a new set of
> predicates about a Collection, and don't include the membership properties
> in the representation, is it permissible for the server to ignore the *lack
> of* those triples?
>
> Otherwise, it seems that you would need to submit the complete
> representation with all, say, 100,000 membership triples, just to change a
> label for the collection.  That would normally be PATCH, I know, but is
> this a known special case or an unintended loophole?
>
> And, to be sure, this would ONLY apply for server managed properties, not
> for other properties where the lack of the property would mean to delete
> any existing triple, and to do otherwise would require PATCH.
>
> Thanks!
>
> Rob
>
> ----
> 4.2.4.1 If a HTTP PUT is accepted on an existing resource, LDP servers
> must replace the entire persistent state of the identified resource with
> the entity representation in the body of the request. LDP servers may
> ignore server-managed properties such as dcterms:modified and
> dcterms:creator if they are not under client control. Any LDP 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.
>
>
> --
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305
>



-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305