RE: More on ordered collections

OK...:

1) noted and closed.

2) noted and added a sentence clarifying that DELETE MUST NOT affect the
ordering of the remaining members.

3) noted as open issue [1]  -- suggest not to do anything about it unless
more people speak up in favor of requiring a specific server behaviour.


Regards,

Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html#rfc.issue.6.1-when-are-members-added>

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Wednesday, April 16, 2003 11:58 PM
> To: 'Webdav WG'
> Subject: 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-proto
col-latest
.html>

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

Received on Thursday, 17 April 2003 12:11:00 UTC