- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 12 Jun 2003 12:59:38 +0200
- To: "WebDAV" <w3c-dist-auth@w3.org>
- Cc: <hardie@qualcomm.com>, "Jim Whitehead" <ejw@cse.ucsc.edu>
Hi. Ted Hardie has raised the following issue with the current draft of the ordering protocol... In section 6.1 we say: "Note to implementors: this specification does not mandate a specific implementation of MOVE operations within the same parent collection. Therefore, servers may either implement this as a simple rename operation (preserving the collection member's position), or as a sequence of "remove" and "add" (causing the semantics of "adding a new member" to apply). Future revisions of this specification may specify this behaviour more precisely based on future implementation experience." The issue here is that *if* we don't want to mandate a specific server behaviour, we should at least give client developers some guidance about how to achieve what they want (in this case a simple "rename" within the same parent collection where the ordering -- if present -- is preserved). The pseudo-code for this would be: 1) PROPFIND/Depth 1 on parent collection, getting DAV:ordering-type 2) if DAV:ordering-type not present or == "dav:unordered", just proceed as before 3) determine position of member to be renamed (such as "first" or "after x") 4) add Position header to MOVE request, specifying the previous position This should work with both kinds of servers (the one implementing this as UNBIND/BIND will obey the Position header, the other one will simply ignore it and thereby preserve the ordering). Is everybody OK with this example being added to the draft? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 12 June 2003 06:59:46 UTC