RE: More on ordered collections

OK, this answers a lot of my questions.


> > > >  - If I MOVE a resource within the same collection, 
> must the server
> > > > preserve its ordering position wrt other resources?
> > >
> > > That depends on the Position header:
> >
> > What happens if the Position header is not present?  Must servers
> > preserve the ordering or lose it?
> 
> It must order it at the end. See above.

I think this is the wrong behavior.  A MOVE within a collection is
simply a rename.  A server ought at least to be able to preserve the
ordering if Office/Web Folders does a rename.  Otherwise this
unnecessarily disturbs the author's ordering.  If we don't say "a server
MUST retain the relative position of a member when it is moved within
the same ordered collection without an explicit Position header", then
it should at least be a SHOULD.

> > >  - 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.
> >
> > 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.
> 
> 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. Please take
> this to the ACL list if you feel this needs to be discussed.

ACL isn't the issue -- it was just an illustration.  

If you COPY some content into an ordered collection, overwriting an
existing resource, what is the right thing to do?  I think the right
thing to do is to preserve the target resource's position.  Suggested
language:

  "When COPY is used to overwrite a member of an ordered collection
without an explicit Position header, the server MUST maintain the
original members position, just as when PUT is used."

If you MOVE some content this is a little more difficult.  Perhaps you
could say "When a resource is moved from outside the ordered collection
into the ordered collection and overwriting a pre-existing member
(without an explicit Position header), the server SHOULD preserve the
pre-existing member's position.  When a resource is moved within the
ordered collection and overwites another internal member (without an
explicit Position header) the server MAY preserve either the source or
the destination's position but MUST NOT arbitrarily reorder the moved
resource to the end of the order."

> > > >  - If I DELETE a resource, must the server preserve the 
> ordering other
> > > > than that deleted resource?  Section 4 could be more 
> explicit that if
> > > > resource C is after B is after A, then the deletion of 
> B means that C
> > > > must be after A rather than destroying the ordering 
> relationship. This
> > > > is worth making explicit because server implementors must either
> > > > maintain their orderings in a format that is irrelevant to what
> > > > resources exist (absolute), or relative orderings must 
> be fixed up
> when
> > > > a resource is deleted.
> >
> > > I think this follows from the definition of "ordering" 
> (repeatability of
> > > PROPFIND result element ordering).
> >
> > Then why not make it explicit in the specification?
> 
> I think it *is* explicit (by definition).

Sorry, how can this possibly be explicit in the definition of the
PROPFIND response?  Unless the spec is clear, what's to stop the server
from arbitrarily reordering the collection (losing some or all of the
ordering information) when a resource is deleted?  After all, any other
write operation in an ordered collection may change the ordering, so the
definition which mentions the PROPFIND response obviously is dependent
on the behavior of write operations in between.

Lisa

> 
> > > > Note that the answers to the MOVE/COPY questions are 
> particularly
> > > > important if WebDAV clients do "Safe-save" operations 
> -- e.g. a client
> > > > that PUTs an new resource then uses COPY to overwrite 
> the existing
> > > > resource after finding that the PUT worked.  There are 
> many other
> > > > variations in safe-save algorithms, some using MOVE.
> >
> > > Those servers will need to set the Position header 
> accordingly if they
> want
> > > the resulting resource to be in the "original" position.
> >
> > It is not the servers doing "safe save" operation, it's the 
> clients, and
> > these may be clients that are unaware of ordering or choose 
> not to set
> > the Position header.
> 
> Correct. This means that these clients will lose the original order
> position.
> 
> > It's important to consider how a server with an ordered collection
> > interacts with ordinary clients (ones that do not use the Position
> > header). Otherwise, an author that tries to keep their collection
> > ordered may frequently find the ordering  unecessarily 
> "messed up" after
> > resources are added, deleted, renamed, or overwritten by 
> non-ordering
> > client software (e.g. Office).
> 
> I agree that this is the case, but it's unclear how we can 
> prevent this. A
> server usually doesn't have the required context to decide 
> what the intent
> of a sequence of operations is.
> 
> Note that Office isn't an issue here because it indeed edits
> (LOCK/GET/PUT/UNLOCK) a single URL. Also note that a similar 
> problem exists
> with RFC3253-style autoversioning. The best way to avoid 
> these issues is to
> use a client which behaves properly (by consistently using 
> the same URL).
> 
> Julian
> 
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
>

Received on Monday, 7 April 2003 14:52:28 UTC