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

RE: More on ordered collections

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 16 Apr 2003 22:26:41 +0200
To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEPFHAAA.julian.reschke@gmx.de>

Trying to summarize the issues raised by Lisa:

1) Concerns that ordering information will be lost when clients not aware of
ordering do "safe updates" (such as writing to a temp file, then moving it
to the original file): I agree that this is less than optimal, but the very
same issues exist with versioning (version history lost) or ACLs. Therefore
I'd say that the ordering spec should not try to fix something that is
inherently broken. The right way to fix this is to have clients that take
advantage of WebDAV properly (for instance doing in-place editing using
LOCKs).

2) More specific language about when ordering information is supposed to be
preserved. Right now, the ordering spec is mainly silent on this issue -- it
only defines specific behaviour for the case when new collection members are
added. In particular, Lisa mentioned DELETE which should not affect the
ordering of other members in the collection. I think this is obvious and
doesn't need to specified separately, but I'm willing to add a few sentences
if others feel this should be addressed (my point being: removing one member
from an ordered set doesn't affect the ordering of the remaining members).

3) The spec currently avoids to completely specify about *when* a new
collection member is added. Obviously this is the case for MKCOL and
PUT/COPY [when not updating an existing resource] (as stated in section
6.1), but what about MOVE? I can imagine servers that implement MOVE as a
sequence of LINK and UNLINK, in which case clearly a new binding is being
created and an old one is destroyed. On the other hand, it would be useful
for clients if they could rely on MOVE inside a collection (-> rename) not
to change the ordering. So do we want to mandate a specific server behaviour
(making it harder for server implementors), or leave it as it is (making it
harder for clients)?

Feedback appreciated.

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 16 April 2003 16:26:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT