RE: Review of ordering draft, version 05

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Wednesday, February 26, 2003 11:51 PM
> To: 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
>
>
> ...
>
>    Of course they are meant to be atomic. In fact, I don't agree that
>    this needs to be clarified.
>
>    RFC3253 says:
>
> 	   'A "postcondition" of a method describes the state of the
>    server that must be true after that method has been completed.'
>
> This implicitly meant "completed successfully".  If the method fails,
> all bets are off.  By "partially succeed", I meant "made only some of
> the changes that the postconditions require" (and therefore returns a
> "failure" status).  An example of such a method is MOVE or DELETE on a
> collection, which is allowed to move or delete some of the members
> even if it fails (i.e. only "partially succeeds").
>
>    Having a *set* of postconditions simply means that the state
>    changes have been broken down into separate items, it does *not*
>    mean that some of them are optional.
>
> But without an explicit declaration of atomicity, a failure might
> indicate "partial success" (i.e. some of the postconditions were
> produced).

Well, in the case of an internal server error, obviously this may happen.
There are simply kinds of errors that are outside the control of the WebDAV
code handler, such as database connections going down, file system
corruption, manual operator intervention and so on... So even if the spec
mandates atomicity, a client really can't reliably assume what specifically
went wrong when he gets a 500 status, right?

>    The ordering spec uses the same structure as RFC3253 here, and
>    RFC3253 doesn't seem to use the term "atomic" anywhere when
>    specifying multiple postconditions. So if this really is an issue,
>    I think it applies to all specs using this terminology, not only
>    the ordering spec.
>
> There were various debates about what "atomic" means, so the terminology
> used in RFC3253 to indicate atomicity is:
>
> "If an XXX request fails, the server state preceding the request MUST
>  be restored."

I see. So I'd propose to simply add this very sentence to the ORDERPATCH
method description in the final editing pass.

Are we done now? :-)

Julian

P.S.: why doesn't the BIND spec include this magic sentence? Just because
there's only a single postcondition defined for BIND?

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 27 February 2003 02:52:46 UTC