Re: Lack of server controlled property in PUT?

Hi John,



On Tue, Oct 14, 2014 at 7:41 AM, John Arwe <johnarwe@us.ibm.com> wrote:

>
> Also note that HTTP PUT can function semantically as either create or
> update, depending upon the prior existence of the resource identified by
> the request URI.
>

+1.

Is it worth making the distinction clearer in the spec as to how this
affects the interpretation of the requirements for PUT?  Probably not at
this stage, would be my assumption.



> My reading of 4.2.4.1 is that "replace" covers both cases, and 4.2.4.3
> covers modify (hence the change/modify words) but not create; although in
> practice since it is true as you note that servers can reject requests for
> all sorts of reasons, my "but not create" might make no practical
> difference.



> 1: write-once (by client) ... e.g. dcterms:previousVersion
> > Doesn't this conflict with the note in .3 that says write-once
> > properties are *not* server-managed?
>
> Sigh, more sub-cases.
> Nice to have a fresh reader who still sees the words as written instead of
> the cached copy in my wetware.
>
:) Sorry for the pedantics.

> My best (albeit weaselly and weak) backward-looking defence is to point
> out that the note is non-normative.
>
It is ... but it would not be good to have a note that conflicts with the
normative text.



> More germanely though, "write-once" != "write on create only"; "write on
> create only" and "write once after create" are arguably distinct sub-cases
> if we continue to rely on the CrUd distinctions, which I think will help
> readers more than it will harm them.
>
Agreed.
Rather than bogging down the spec with all of the distinctions, perhaps
they belong in an ancillary (but linked) document, with non-normative
clarifications pointing back into the spec for the clauses that affect them?


> Implementers MAY WISH TO [1] apply 4a or 4b in different situations
> > according to how they consider a particular property.
> We appear to have consensus on this.
> (And let anyone with a lesser-degree belt in RFC-foo be April-fooled into
> thinking 6919 supersedes 2119, look at its publication date and status -
> Google isn't the only org that does April Fool's jokes.)
>
MAY WISH TO was very carefully chosen ;)

> LDP servers MAY ignore properties that have server supplied values,
> > including their omission from the body of the request.
>
> I don't see a definition for "server supplied", so I cannot comment on the
> utility of this change.
>

Sorry, that must have been part of a previous draft.



>
> > - .3 applies to containership triples, and possibly moves up to General
> > ...
> > And isn't there a conflict already?
>
> I don't think there's a conflict in today's text.  [snip]
>

Okay, I see the logic, thank you for the clarification :)



> I wonder out loud if we change (really: add) the definition+name of
> "server-managed" to be "LDP-server-managed", to be as constrained by the
> LDP spec, and then note (perhaps alongside, or with link to, 4.2.1.6) the
> existence of additional constraints (not LDP imposed) that the server might
> have for rejecting any request), is this neatly wrapped up?
>
> The thinking being that
> - calling them "LDP-server-managed" [wham] baby seals readers each time it
> comes up
> - using that term consistently in place of today's varying language [wham]
> shaves off another set of unintended readings
> - explicitly mentioning the (now distinct rather than overlapping) issue
> of other non-LDP constraints causing requests to be rejected [wham]
> untangles it from the LDP requirements
>
Yes. Please. :) I think this would make the spec significantly clearer,
reducing confusion in readers (such as myself!), and thus increasing the
interoperability of products [legitimately or not] claiming conformance.

Rob

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