Summary: Ordered Collections

This post represents my best effort to summarize the "ordered collections" 
thread which occurred primarily at the end of October.  Feel free to ammend 
this post if you feel I have trivialized or misunderstood your position.

There were three parts to this thread:
1) A requirements discussion concerning support for ordered collections.
2) Sketches of two proposals for specifying ordering of new members of an 
ordered collection
3) Creation of ordered collections using MIME multipart messages.

The first item is a meta-discussion over whether the functionality should 
be included in WebDAV at all.  There was some agreement that if you do want 
to support this capability, you need to allow the creation of new compound 
documents in one action (the creation using MIME discussion), and to insert 
new members of a compound document in a specific location in the document, 
which leads to the discussion of proposals for ordering.

Requirements Discussion:

The case in favor of ordered collections states that ordering is useful for 
modeling compound documents [1][2][3], making certain document management 
applications "substantially easier"[4] to build on top of WebDAV, and for 
recording the order that sets of changes are applied to a server [5].

The case against ordered collections was summarized nicely by Jim Davis 
[6].  In short, the objections center on the difficulty for servers of 
implementing ordered collections [7][8], especially servers which use a 
filesystem as their repository, the difficulty for older clients of 
understanding new WebDAV-specific compound document formats [8], and some 
concerns over just how well compound documents can be modeled by 
collections [9].

[1] Jim Davis, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0066.html
[2] Judith Slein, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0075.html
[3] Judith Slein, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0092.html
[4] Jim Davis, http://lists.w3.org/Archives/Public/w3c-dist-auth/1997Oct  
Dec/0123.html
[5] Stephen Martin, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0166.html
[6] Jim Davis, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0126.html
[7] Yaron Goland, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0104.html
[8] Yaron Goland, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0124.html
[9] Yaron Goland, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0067.html


Specifying ordering of new members of an ordered collection:

Two sketches of proposals for ordered collection support were made on the 
mailing list.  The first proposal [1] involved using extra headers for PUT 
and ADDREF to specify the URL of a member of the collection which must come 
before the new resource being created by PUT, or added by ADDREF.
The second proposal [10] suggested the use of a 'next-member' property to 
model the ordering of members in a collection, essentially creating a 
linked list.

[10] Martin Duerst, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0138.html


Creating new compound documents in one operation:

Discussion here centered on defining the relationship between MIME 
multipart messages and WebDAV collections [11], and on defining how to use 
MIME multipart messages with MKCOL or PUT [12].  The use of the MIME type 
multipart/related was recommended for use in transmitting compound 
documents [13].

[11] Larry Masinter, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0068.html
[12] Judith Slein, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0101.html
[13] Larry Masinter, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997OctDec/0113.html

- Jim Whitehead <ejw@ics.uci.edu>

Received on Sunday, 30 November 1997 19:43:00 UTC