RE: More on ordered collections

> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Monday, April 07, 2003 8:52 PM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: 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.

OK, you got me there :-)

The default of "end-of-ordering" in the absence of the Position header is
specified for the case where a new collection member is *added*. A MOVE can
be seen both as

1) removing a binding and adding a new binding or
2) renaming a binding.

Depending on which point of view you take, you are or you aren't adding a
new collection member. The ordering spec currently is silent on how a
collection-internal MOVE needs to work, and I'm not sure that it would be a
good idea to get into the business of  defining this

> 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

I disagree here -- a MOVE within a collection *can* be implemented as a
simple rename, but no spec currently forces servers to behave that way.
RFC2518 defines COPY/DELETE semantics, the binding spec (I think) sees it as
BIND/UNBIND.

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

This would definitively be useful for the average client. Does anybody have
a problem with making this a SHOULD?

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

It was a *good* illustration. This is a very important issue where I think
you are wrong (because the ACL spec clearly says that MOVEing a resource
must preserve it's access rights). You really should raise this on the ACL
list.

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

It depends on the same question as above: is a new collection member added
or not? I don't think the ordering spec should get into the business of
defining this (RFC2518bis possibly should).

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

Again, the ordering spec defines the behaviour based on the condition of
whether new internal members are added or not. I think it's consistent in
this regard. Mandating a specific behaviour here won't fly -- if we really
want to make this consistent between specific implementations, we should try
to clarify this in RFC2518bis (the behaviour for ordered collections will
then follow automatically).

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

It follows from the definition of ordering. Removing an element from a fully
ordered set doesn't affect the ordering of the remaining elements. If "a"
was "before" "c" before the DELETE of "b", it still will be before it after
the operation.

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

No, that is not the case. No write operation will have side-effects to the
ordering of existing members. A newly added member is simply inserted at a
specific position in the ordering, but the ordering of the previously
present elements will still be the same.


Julian


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

Received on Monday, 7 April 2003 15:27:26 UTC