W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Review of ordering draft, version 05

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 24 Feb 2003 19:48:54 +0100
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEBLGJAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, February 24, 2003 3:38 PM
> To: 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>    > From:  Lisa Dusseault
>    > Are we possibly making things confusing by introducing a
>    > postcondition "code" like (DAV:ordering-type-set) for something that
>    > MUST be done?  It makes it seem like the server might choose
> not to set
>    > the ordering type, create the collection anyway, and respond with 409
>    > containing <DAV:ordering-type-set/>.
> Whether or not a particular request may "partially succeed" is up
> to the definition of that request.  Most RFC3253 methods are defined
> to be atomic, i.e. they either succeed or they have no effect on
> the server state.  The reason that multiple postconditions are
> defined for an atomic operation is to allow the server to give the
> client a more precise idea about which of the semantics of the
> request could not be achieved (the client can then use this
> information to give the user a better error message).
> WRT to the specific example mentioned here, I agree that this issue
> should be addressed by the ordering protocol, by having it state
> whether the methods it is defining/extending are atomic, or whether
> they are allowed to partially succeed.  I recommend that they be
> required to be atomic.
> ...

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

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.

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.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 24 February 2003 13:49:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC