RE: More on ordered collections

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, April 08, 2003 12:19 AM
> To: 'Webdav WG'
> Subject: RE: More on ordered collections
>
>
>
> One thing that I would suggest is to never try to define semantics for
> both COPY and MOVE at the same time (they have radically different
> semantics, in spite of what 2518 incorrectly implies, as acknowledged
> by the authors of 2518 :-).  In particular, in the following
> discussion, what Lisa says is true for COPY while what Julian says is
> true for MOVE.  In particular:
>
>    > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
>    > >
>    > > If I MOVE or COPY a resource into a collection, overwriting
>    > > a resource that has an ordering position, is that ordering
>    > > position (of the destination) preserved?  Usually not, as
>    > > RFC2518 defines an Overwrite to be implicitly DELETE the
>    > > target.

That's why I wrote *usually* here.

> I believe that we have consensus that 2518 is wrong here
> (this is explicitly pointed out in 3253) and that Overwrite is
> only a DELETE for MOVE, not for COPY.

That would be good. Do we? Anyway, this should be clarified in RFC2518bis.

>    > From: Lisa Dusseault
>    >
>    > No, I disagree with this.  Overwriting a regular resource does
>    > not reset all the live properties.  For example, it would be
>    > pretty disastrous for the ACL property to be reset every time a
>    > resource is overwritten.
>
> Here Lisa is talking about COPY behavior.
>
>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
>    If you do that using a MOVE? I *really strongly* disagree. ACLs are
>    properties of a resource, not of it's binding/URL. MOVEing a
>    resource MUST move it's ACL with it, overwriting the target
>    resource's ACLs.
>
> And here Julian is responding with MOVE behavior.

That *may* be the source for the confusion.

However I've got the impression that Lisa would like servers to better
support the following request chain ("safe delete"):

GET A
PUT A.bak
MOVE A.bak -> A

or similarily

GET A
MOVE A -> A.bak
PUT A
DELETE A.bak

Under this scenario, a resource would usually lose it's ordering position.
However, it would also lose it's version history and it's ACL, so I fail to
see why this would be a specific problem with the ordering spec.

However, if the client would issue these requests:

GET A
PUT A.bak
COPY A.bak A
DELETE A.bak

and the server conforms to the RFC3253 COPY semantics, there wouldn't be any
problem with ordering, ACLs or version history (the ordering spec just
"inherits" from the server's view of what COPY/Overwrite means).

So if at the end of the day we agree that COPY should always have RFC3253
sematics, I'm all for it :-) I just didn't want the ordering spec to require
a specific model.


Julian


P.S.: these "safe delete" scenarios obviously can become problematic if the
client doesn't properly handle dead properties.


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

Received on Monday, 7 April 2003 18:52:45 UTC