More on ordered collections

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.

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
other children.  I believe this is already clear through the term
"member" even though none of the examples show a sub-collection.

Other questions
 - If I MOVE a resource within the same collection, must the server
preserve its ordering position wrt other resources?
 - 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?
 - 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?
 - 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.

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.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Sunday, April 06, 2003 12:17 PM
> To: Webdav WG
> Subject: RE: Ordered collections and versioned collections
> 
> 
> 
>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
> 
>    > From:  Clemm, Geoff
>    >
>    >    From: Lisa Dusseault [mailto:lisa@xythos.com]
>    >
>    >    It seems from draft-ietf-webdav-ordering-protocol-07 that only
>    >    version-controlled resources are part of the ordering of
>    >    version-controlled collections (Section 9: "for 
> compatibility with
>    >    RFC3253, only the ordering of version-controlled 
> members needs to
>    >    be maintained")
>    >
>    >    Does that mean there's no way to order versioned and 
> unversioned
>    >    resources together within a version-controlled collection?
>    >
>    > That is correct.  The issue is that when you UPDATE a
>    > version-controlled collection with a new version, it can 
> change the
>    > set of version-controlled members, and there would not 
> be a way to
>    > define what the ordering of the existing non-version-controlled
>    > members should be wrt the new version-controlled members.
> 
>    For instance, we can define that the UPDATE operation does not
>    define the ordering of those members (that is, the server (a) may
>    insert them in arbitrary places or (b) must insert them at the
>    end). Currently the postcondition is:
> 
>    "(DAV:update-version-controlled-collection-members-ordered): If the
>    request modified the DAV:checked-in version of a version-controlled
>    collection and the DAV:ordering-type for the checked-in version is
>    not unordered ("DAV:unordered"), the version-controlled members
>    MUST be ordered according to the checked-in version's
>    DAV:version-controlled-binding-set property."
> 
>    How about adding:
> 
>    "Members that are not version-controlled MUST be moved to 
> the end of the
>    ordering (in no particular order)."
> 
>    This behaviour would be consistent with section 6.1 
> (setting the position
>    when no ordering information was specified).
> 
> That would be fine with me, or just saying that the order of the
> non-version-controlled members is server-defined following the UPDATE.
> 
> Cheers,
> Geoff
> 
>

Received on Sunday, 6 April 2003 16:08:36 UTC