Re: Lack of server controlled property in PUT?

Hi Rob,

On Thu, Oct 9, 2014 at 11:33 AM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
>
>
> On Thu, Oct 9, 2014 at 5:58 AM, Steve Speicher <sspeiche@gmail.com> wrote:
>
>> On Thu, Oct 9, 2014 at 8:45 AM, Yves Lafon <ylafon@w3.org> wrote:
>>
>>> On Wed, 8 Oct 2014, Robert Sanderson wrote:
>>>
>>>> 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!)
>>>>
>>>
>>> I don't see the inconsistency here, one means mostly "client can try to
>>> modify it" even the change will not take place (like dcterms:modified that
>>> might be computed automatically), the second means "client is not allowed
>>> to try to change it", and 403 should be a better signal than 409 here.
>>>
>>> I don't see the inconsistency either, agreeing with Yves.  We had a
>> fairly long discussion on suggested status codes, resulting in the language
>> of "typically 409", of course other may be valid for other cases.
>>
>
> When a client tries to change a server-managed property that is not under
> client control, does the server ignore the property and accept the rest of
> the request (under 4.2.4.1) or return an error for the entire request
> (under 4.2.4.3)?
>
> It clearly cannot do both.   Or can it do either, at its discretion ...
> making 4.2.4.1 useless in practice as clients would have to allow for the
> situation when the server errors, and thus should always send the current
> value for the property.
>
>
Maybe a sample will help illustrate what these 2 clauses are trying to say,
then we can figure out how we could say it better.

Take an example where I want to get a driver's permit at my local friendly
DMV, one could imagine a simple sample that could express the creation or
issuing of such a permit:

@prefix dmv:   <http://ncdmv.org/ns#>.

<> a  dmv:DriversPermit ;
  dmv:dateOfIssue "2014-10-10T12:18:36.833Z";
  dmv:issuer <http://ncdmv.org/staff/gloria>;
  dmv:driver <http://ncdmv.org/drivers/steve>.


POST'ing this and fetching the results would yield these statements:

    <http://ncdmv.org/permits/driver/steve>
        a                             <http://ncdmv.org/ns#DriversPermit> ;
        <http://ncdmv.org/ns#dateOfIssue>
                "2014-10-10T12:18:36.833Z" ;
        <http://ncdmv.org/ns#driver>  <http://ncdmv.org/drivers/steve> ;
        <http://ncdmv.org/ns#issuer>  <http://ncdmv.org/staff/gloria> ;
        <http://purl.org/dc/terms/identifier> "37294s234;
        <http://purl.org/dc/terms/contributor>
                <http://localhost:8080/ldp/user/ldpuser> ;
        <http://purl.org/dc/terms/created>
                "2014-10-10T12:21:28.79Z"^^<
http://www.w3.org/2001/XMLSchema#dateTime> ;
        <http://purl.org/dc/terms/creator>
                <http://localhost:8080/ldp/user/ldpuser> ;
        <http://purl.org/dc/terms/modified>
                "2014-10-10T12:21:28.79Z"^^<
http://www.w3.org/2001/XMLSchema#dateTime> .

As you can see, I have more "stuff" added by the server.  The idea is,
whether the client sends these "server-managed" properties or not, some
implementations can silently ignore them and successfully process the
PUT/update (4.2.4.1) dc:creator, dc:modified, dc:created, dc:contributor,
dc:identifier.  Note some truly unconstrained raw-storage kind-of LDP
servers, may have none of these.  Some application-constrained LDP servers,
they may have a number of these

On the other hand, same clients may be able to change triple with
dmv:issuer, though most likely only privileged users (system
administrators, high level supervisors, etc).  You would NOT want the
server to silently ignore these updates (4.2.4.3).  As the values are
completely under the control of the client, depending on when the resource
was created and who is doing the updates.

So this is the intent of these 2 conformance clauses, which seem to be
causing some confusion as written (maybe my example helped or not).  If
this helps, perhaps we can next look at where the ambiguity is coming in
with current writeup.

Regards,
Steve



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