RE: Postconditions with no XML elements defined?

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.

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".

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.

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

Regards,
--
Peter Raymond - MERANT
Technical Architect (ADM)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com