W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2003

RE: Consideration of WebDAV Ordered Collections Protocol as Proposed Standard

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>
Message-ID: <JIEGINCHMLABHJBIGKBCOENKHIAA.julian.reschke@gmx.de>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT