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: Sunday, April 06, 2003 10:09 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: 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.

Yes.

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

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

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

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

That depends on the Position header:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

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

Same:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>


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

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

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

Julian

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

Received on Monday, 7 April 2003 08:11:43 UTC