W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: Postconditions with no XML elements defined?

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 12 Jul 2001 10:36:33 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1038E2268@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]

   Peter Raymond <Peter.Raymond@merant.com> wrote:

   > Tim says:
   > > It simply means that DeltaV is using the definitions found in
   > > RFC2616 and is not redefining their meanings.  In preactise this
   > > means that server >implementers can choose within those guidelines,
   > > but I think we should agree between ourselves which are which.
   > Also sounds like a good idea, but could be a big job to review
   > each pre/post condition and decide under what circumstances a
   > 409 or a 403 should be returned.

   I did that a while ago, and it was not such a big deal

Also, whether or not a particular response should be a 403 or a 409
depends on the particular request and on the implementation of the
resource.  For example, with the DAV:preserve-versioning-properties
postcondition and a MOVE request on a checked-out version-controlled
resource, one server might not be able to preserver versioning
properties so it returns a 403 indicating the MOVE will always fail,
while another server might only be able to MOVE only checked-in VCR's,
so it returns a 409 (since the user could MOVE the resource after
checking it in).

So we could compile a non-normative list of what status codes are
likely to be returned by certain implementations, but a client writer
should not use this list (it should use the status code actually
returned), and a server writer should only use the list if it reflects
the implementation choices made by that server.  I would be strongly
against including such a list in the protocol itself, since it would
be too easy for a client writer to hardwire these "suggested" return
codes into their implementation logic.

   > While we are on the subject of pre/post conditions I also wonder
   > if anyone can explain why the post condition XML elements are not
   > worded as "negatives", but the preconditions are worded as
   > "negatives".

   They are not all that way.  The preconditions are statements that must be
   true for a method to succeed, and the postconditions are statements that
   must be true immediately after the method has suceeded.
   Don't think of them as error descriptions.


   > I am just intrigued as to why they got worded this way.  The status
   > code already indicates that something is forbidden (403) or there
   > is a conflict (409).  So you could actually argue that we should
   > remove the "negatives" from all the elements (pre and post)...eg in
   > the above example we should have:
   > DAV:referenced-version
   > DAV:predecessor-set

   I prefer the more descriptive names.

As do I.

Received on Thursday, 12 July 2001 10:37:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC