WebDAV Advanced Collection Requirements Redmond, June 16, 1998

Terminology Referential Member Resource: A member resource that has no content of its own, but rather is a reference to another resource Target Resource: The resource referenced by a referential member of a collection Strong Reference: A reference whose referential integrity is guaranteed by the server Weak Reference: A reference whose referential integrity is not guaranteed by the server

Referential Members (1) 3.1.1 The same resource may be referenced by referential members of multiple collections. 3.1.2 The same resource may be referenced by more than one referential member of the same collection. 3.1.3 It is possible for the same resource to be an internal member of a collection and also to be referenced by one or more referential members of that same collection.

Referential Members (2) 3.1.4 Operations on a referential member do not affect the resource it references [except as needed to enforce referential integrity]. 3.1.5 Operations on a resource do not affect references to it [except as needed to enforce referential integrity]. 3.1.6 For any referential member of a collection, it is possible to obtain the URI of the resource it references. Proposed changes to what the draft currently says are in red. Morris Matsa pointed out the need for the qualifications. One way to enforce referential integrity might be to store a list of strong references to a resource on that target resource, so that when it is moved or deleted, it knows which resources to inform of the change -- so we need to qualify 3.1.4. 3.1.5 needs to be qualified to allow strong references to be changed when their targets move.

Referential Members (3) 3.1.7 It is possible to add a referential member to a collection. 3.1.8 It is possible to remove a referential member from a collection. 3.1.9 It is possible for a referential member of a collection to carry its own properties, distinct from those of the resource it refers to. 3.1.15 A referential member of a collection is itself a resource. 3.1.15 is new since the last time the requirements were presented. It makes explicit one implication of 3.1.9. Since DAV properties can only belong to resources, referential members must be resources.

Referential Members (4) 3.1.10 A listing of members of a collection shows both the internal members and the referential members. 3.1.12 For any member of a collection, it is possible to discover whether it is an internal or a referential member.

Referential Members (5) 3.1.11 It is possible to request creation of a referential member that the server will guarantee to have referential integrity. 3.1.13 It is possible to discover whether a referential member is a strong reference or a weak reference. 3.1.14 It is possible to discover whether a resource is the target of a strong reference. 3.1.11 and the related requirementes were added as a result of the LA discussions.

Ordered Collections (1) 3.2.1 Ordering is sufficiently standardized that different applications and servers can operate on the same ordering without private agreements. 3.2.7 It is possible to order the members of a collection in a client-specified way, not necessarily based on property values. 3.2.2 A collection is not required to be ordered. 3.2.3 The semantics of an ordering are discoverable. These are the fuzzy / controversial requirements about ordered collections. I think I added 3.2.2 since the previous draft. It expresses something that I’ve always assumed to be true, but it will be interesting to see what others think.

Ordered Collections (2) 3.2.4 Each collection member must appear in the ordering exactly once. 3.2.8 Internal and referential members may be intermixed in the same ordering. 3.2.5 An ordering must not include any resources that are not members of the collection. 3.2.n Only one ordering can be attached to a collection. 3.2.5 was not explicit before. 3.2.n is not currently in the draft, but I think based on the LA discussions, people wanted it to be there. So I’m proposing to add it.

Ordered Collections (3) 3.2.6 When a client requests a listing of the members of a collection, this listing is returned in the order specified by the collection. This has been strengthened since the previous draft, which only required a way to request an ordered listing.

Information Requirements draft is at: Author can be reached at: http://www.ics.uci.edu/~ejw/authoring/collection/draft-ietf-webdav-collection-reqts-01.txt Author can be reached at: slein@wrc.xerox.com