RE: More on ordered collections

Sorry, I must not have been sufficiently clear in my questions.  I'm
mostly discussing operations without the Position header -- operations
with clients that aren't aware of ordering.

> > Is the position of a newly-defined resource in an ordered collection
> > treated the same way by all servers?   It would be nice to 
> be specific
> > about how new resources are added to an ordered collection.

So this meant, how are resources added to a client-ordered collection
when the Position header is missing? Must servers add them to the end of
the ordering or can they be put at the beginning or anywhere?

> > I assume that sub-collections are orderable as well? That 
> is, if I have
> > an ordered collection containing several sub-collections, I 
> assume I can
> > define an ordering that includes all sub-collections along with all
> 
> Nope. Ordering is a property of the internal (!) members of a 
> collection, so
> it doesn't automatically affect child collections:

Again I was unclear.  I meant direct sub-collections, or collections
which are direct children of the ordered collection. These are ordered
together with regular child resources, correct?  There are no examples
of this but I believe this is what the spec says.

> > Other 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?

> >  - If I COPY a resource within the same collection, where is the new
> > resource placed in the ordering -- next to the old resource (closely
> > preserving its ordering semantics), or at the end, or arbitrary?
 
And here, what happens if the COPY method has no Position header?

>  - 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.
Besides, the ordering is a property of the parent, not the resource
being overwritten.  I would expect that ordering would be preserved, but
the spec ought to say one way or another.


> >  - 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?

> > 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.

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).

Lisa

Received on Monday, 7 April 2003 13:40:23 UTC