RE: More on ordered collections

I agree with (1).

For (2), I agree that it is obvious, but I have nothing against adding a
sentence or two to make the obvious explicit (:-).

For (3), I don't think making a special case for "move within a collection"
vs. "move outside of the collection" is worth optimizing, since it makes the
spec more complicated and is likely to be enough of a problem to some
servers to make it likely to not be followed anyway.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, April 16, 2003 4:27 PM
To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: More on ordered collections 


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 17:57:41 UTC