RE: More on ordered collections

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Monday, April 07, 2003 7:40 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> Subject: 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?

At the end. See:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#rfc.section.6.1.p.2>

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

Sure. Collections are resources. If a collection appears as a direct member
of an ordered collection, it behaves (ordering-wise) just like a plain
resource.

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

It must order it at the end. See above.

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

See above.

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

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

It says:

"If the request is replacing an existing resource, the server MUST preserve
the present ordering.
If the request is adding a new internal member URI to the collection, the
server MUST append the new member to the end of the ordering."

So the ordering spec basically delegates the decision to the server
implementor (it depends how overwrite operations are implemented
internally) -- I'm not sure we can be more precise here because it might be
impossible or very expensive to implement in some cases.

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

> > > 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:16:52 UTC