RE: Postconditions with no XML elements defined?

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

> Tim says:
>
> >I'd be inclined to name all the pre-postconditions, even if
> > it is unlikely that a client will ever see them coming back
> > from a server I think it is useful to name them so we can
> > talk about them and refer to them easily.
>
> I Agree.
>
> 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
(
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2000OctDec/0125.html)

however, there was a large grain of salt used when deciding between 403 and
409.  If there is interest in re-doing that list I'll happily do so, but
wherever there is a disagreement about if it should be one or the other I
will not offer any resistance :-)

> 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.  I guess there are
more cases of a resource must not be (of a certain type | in a certain
state | whatever) for preconditions than there are for postconditions.

> For example on DELETE in section 3.12 we have:
>
> DAV:cannot-delete-referenced-version as a precondition.
> I like the wording of this XML element it is clear that you have
> done something that is forbidden (eg it says cannot).
>
> BUT in the same section we have:
>
> DAV:update-predecessor-set as a postcondition.
> Why didn't we call this XML element DAV:update-predecessor-set-failed
> or some wording that indicates failure.

Because the postcondition (i.e. that which must be true) is that the
predecessor set was updated.  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.

Regards,

Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

Received on Wednesday, 11 July 2001 09:51:02 UTC