Re: Server behaviour on PUT

El 17/05/13 19:40, Steve Speicher escribió:
>
>
>
> On Thu, May 16, 2013 at 10:21 AM, Raúl García Castro <rgarcia@fi.upm.es
> <mailto:rgarcia@fi.upm.es>> wrote:
>
>     Dear all,
>
>     [[
>     4.4.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.
>     ]]
>
>     Currently there are no restrictions on the representation of
>     resources allowed by a server. Therefore, an LDPR representation
>     submitted by a client may include properties that will be ignored by
>     the server and properties that will not be ignored by the server.
>     Besides, the LDPR representation provided by a server may include
>     properties submitted by the client and properties not managed by the
>     client (e.g., timestamp). Right now it may happen that all the
>     properties in the client representation are ignored and the server
>     representation includes only server managed properties (i.e., the
>     specification does not restrict this).
>
>     In summary, when a client updates a resource anything can happen.
>     E.g., the server may ignore every property stated by the client.
>     However, the specification seems to indicate the contrary, that all
>     the properties exposed for an LDPR can be freely updated by a client.
>
>     While this can be the case for vanilla LDP servers, which don’t take
>     into account the contents of resources, it does not hold for
>     domain-dependent LDP servers that expose data for whom specific
>     restrictions apply, i.e., certain properties are not under the
>     control of the client.
>
>     At the same time, this MUST clause does not align with what is said
>     in the next MAY clause on the same point, which asserts that LDP
>     servers can ignore server managed properties.
>
>     A collateral effect in terms of testing is that, since LDP servers
>     are not forced a minimum behaviour on PUT, no data validation is
>     possible (e.g., we can only check that a different ETag is returned
>     on the updated resource).
>
>     Proposal:
>
>     Rewrite clause 4.4.1 making clear that only the part of the LDPR
>     state that is under the control of the client will be updated with
>     the contents of the representation, and that it is the
>     responsibility of the LDP server to define which parts of the
>     representation are under its control.
>
>
> I think the 4.4.* sections cover this already, reading 4.4.3 and 4.4.4.
>   It is hard to put everything into 4.4.1 itself.  I'd be interested to
> hear others opinion or see what language in the following sections
> doesn't meet this need.

Hi Steve,

In the same 4.4.1, the statement "LDPR servers MUST replace the entire 
persistent state of the identified resource with the entity 
representation in the body of the request" is an absolute requirement, 
and the following MAYs cannot modify this behaviour on an LDP server.

Then, it is the matter of language. For example, in 4.4.*, in several 
cases what is being restricted in the specification is the behaviour of 
LDP clients and not of LDP servers.

 From my point of view, we have to define in the specification the 
restrictions on servers (which is what we will be defining test cases 
and conformance levels for) and not on clients.

For example, the text in 4.4.4:
"LDPR clients SHOULD assume that an LDPR server could..."
does not directly specify the behaviour of a server, it could perfectly 
be rewritten to:
"LDPR servers MAY..."

Kind regards,

-- 

Dr. Raúl García Castro
http://delicias.dia.fi.upm.es/~rgarcia/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Monday, 20 May 2013 11:19:31 UTC