WEBDAV Working Group J. Slein
INTERNET DRAFT Xerox Corporation
<draft-ietf-webdav-collection-reqts-00> March 11, 1998
Expires September 16, 1998
Requirements for Advanced Collection Functionality in WebDAV
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress".
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments
to the Distributed Authoring and Versioning (WebDAV) working group
at <w3c-dist-auth@w3.org>, which may be joined by sending a
message with subject "subscribe" to <w3c-dist-auth-
request@w3.org>.
Discussions of the WEBDAV working group are archived at URL:
<http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.
Abstract
The base WebDAV protocol [Goland et al., 1998] provides basic
support for collections. It defines a MKCOL method for creating
collections and specifies how other HTTP and WebDAV methods
interact with collections. It supports only internal members of
collections, which it defines as members whose URIs are
immediately relative to the URI of the collection.
This draft sets out requirements for more advanced, optional
collection functionality. It extends the base functionality in two
general directions: support for referential members, and support
for ordered collections. A separate WebDAV specification is
expected to define protocol elements providing the functionality
described here.
Slein [Page 1]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
1 Terminology
The terminology used here differs from that in the base WebDAV
protocol specification [Goland et al., 1998], particularly in its
definition of internal member resource.
Collection
A resource that contains member resources
Member Resource
A resource contained by a collection
Referential Member Resource
A member resource that has no content of its own, but rather is
a reference to another resource
Internal Member Resource
A member resource that either has content of its own or is
empty, but is not a reference to another resource
Target Resource
The resource referenced by a referential member of a collection
2 Introduction and Rationale
The simple collections that the base WebDAV specification supports
are powerful enough to be widely useful. They provide for the
hierarchical organization of resources, with mechanisms for
creating and deleting collections, copying and moving them,
locking them, adding resources to them and deleting resources from
them, and getting listings of their members. Delete, copy, move,
list, and lock operations can be applied recursively, so that a
client can operate on whole hierarchies with a single request.
Many applications, however, need more powerful collections. There
are two areas in particular where more powerful functionality is
often needed: referential members and ordering. This draft
details the additional functionality that is needed in these two
areas.
The requirements have been discussed to some extent on the WebDAV
mailing list, but still contain much that is controversial.
Slein [Page 2]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
Consequently, this draft should be regarded primarily as a basis
for further discussion.
2.1 Referential Members
Referential members make it possible for many collections, on the
same or different servers, to share the same resource. Because
the collections share the resource by referencing it, only one
physical copy of the resource need exist, and any changes made in
the resource are visible from all the collections that reference
it.
So, for example, the mathematics department at one university can
create a collection of resources on fractals that contains some
local resources, but also references resources at several other
universities.
A manufacturing company develops and maintains its product
maintenance manuals on the Web, with a separate collection for
each product manual. Each manual is divided into sections, one
section for every product component. Since many of the company's
products contain some of the same components, many of the product
maintenance manuals have sections in common. Each manual may have
some unique sections, which are internal members of its
collection. But for product components that are common to
multiple products, the manual has a referential member that
references a resource in a shared library.
2.2 Ordered Collections
It is useful for many applications to be able to impose an
ordering on a collection. In the product manual application
above, the sections of each manual may be ordered so that they can
be printed together as a book. A configuration management
application might use a collection to represent a version series,
in which case the "derives from" relationship might be represented
as an ordering on the collection.
A collection ordering may sometimes be based on property values.
An example of such an ordering is one that is alphabetical by
author's last name, or one from most recent to oldest last-
modified-date. An ordering need not be based on property values,
however. It may be purely arbitrary. A professor may order a
collection of course readings in the sequence that makes sense to
coordinate them with her lectures, not based on any property of
the member resources.
WebDAV already provides the tools for creating and maintaining
ordered collections. One obvious approach is for an application
to create a WebDAV property called "Order" on a collection
Slein [Page 3]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
resource. The value of this property might be a list of the URIs
of the collection members.
What the base WebDAV specification does not do is standardize a
single way to represent orderings for collections.
Different applications and services should be able to operate on
the same collection without private agreements about how to manage
and examine its order. To make this possible, there needs to be a
standard mechanism for manipulating and retrieving the order of a
collection, and a standard representation of the ordering.
In any situation where collaborative management of a collection
takes place, and different authoring tools or WebDAV servers might
be used by the collaborators, standardization is important. It is
also important where a different tool may be used to view the
collection from the one that was used to create it.
So for example, two users from different organizations, using
different authoring tools, are working together to create a
collection. One of the tools uses a property on the collection
called "Order" to store an ordering of the collection. The other
tool uses a property on the member called "SequenceNumber". If
each user adds some members to the collection, there will be no
reliable ordering.
3 Requirements
3.1 Referential Members of Collections
Requirements 3.1.1 - 3.1.5 follow naturally from the definition of
Referential Member Resource. Although the behavior of referential
members could be forced to be different from what is described in
these requirements, the fact that referential members are
references to other resources makes the behavior described here
the natural one, and the easy one to implement.
3.1.1 The same resource may be referenced by referential members of
multiple collections.
This is the primary benefit that referential members bring.
Resources can be shared by multiple collections, which may reside
on the same server as the shared resource or on other servers.
3.1.2 The same resource may be referenced by more than one
referential member of the same collection.
It is often useful to allow the same resource to be referenced in
a collection multiple times. Typically, these are cases where the
Slein [Page 4]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
collection is ordered. Consider a case where a collection
represents a book, with one member resource for each page in the
book. A particular graphic needs to appear in several places in
the book, and so needs to appear in the collection several times.
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.
In the example just described, the collection might contain the
graphic as an internal member, which is also referenced by
referential members of the same collection so that it can appear
multiple times in the book.
3.1.4 Operations on a referential member do not affect the resource
it references.
There needs to be some way to operate on the referential member
itself. If requests to the referential member were automatically
redirected to its target resource, this would not be possible.
In addition, passing operations through to the target resource can
be problematic if the referential member and the target resource
are on different servers. Issues about what credentials to use
would need to be addressed.
For some operations, an option to pass the operation through to
the target resource may be desirable as an efficiency measure.
For example, a lock operation on a collection might have a
parameter that determines whether the targets of referential
members should be locked.
As long as requirement 3.1.5 is satisfied, however, the client can
obtain the URI of the target resource and operate directly on the
target.
3.1.5 For any referential member of a collection, it is possible to
obtain the URI of the resource it references.
This will allow clients to resolve references themselves in order
to operate on the target resources.
3.1.6 It is possible to add a referential member to a collection.
3.1.7 It is possible to remove a referential member from a
collection.
It is important to note that this is a different operation from
deleting the referential member's target resource. According to
Slein [Page 5]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
requirement 3.1.4, operations on a referential member do not
affect the target resource, so removing a referential member from
a collection does not cause its target resource to be deleted.
3.1.8 It is possible for a referential member of a collection to
carry its own properties, distinct from those of the resource
it refers to.
There are properties like "who added this resource to this
collection" and "when was this resource added to this collection"
that clearly belong to the referential member, and not to its
target resource, which may be referenced by referential members of
many collections.
3.1.9 A referential member of a collection also inherits the
properties of the resource it refers to.
We might expect internal member resources and the target resources
of referential members to have properties like "Author" and
"Title", but referential members themselves to have properties
like "AddedBy" and "AddedDate". An end user who asked to see
"Author" and "Title" for all members of a collection would expect
to see these properties for both internal and referential members.
This behavior will be easier for clients to provide if referential
members inherit the properties of their target resources.
Otherwise, the client must go to each target resource separately
and retrieve its properties for display to the user.
This requirement can be regarded as a useful exception to 3.1.4,
with all the problems of violating 3.1.4.
3.1.10 A listing of the members of a collection shows both the
internal members and the referential members.
3.1.11 Servers are encouraged to maintain referential integrity for
referential members as far as possible, but are not required
to do so.
Broken references are, of course, undesirable. Breakage may be
unavoidable when a target resource resides on a different server
from the referential member that references it. Servers can,
however, maintain the integrity of referential collection members
when they receive MOVE or DELETE requests for resources under
their own control. They are encouraged, but not required, to do
so.
3.1.12 For any member of a collection, it is possible to discover
whether it is an internal or a referential member.
Slein [Page 6]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
Particularly if operations on referential members are not passed
through to their targets, it is important for clients to be able
to discover which members are referential. Then the client can
resolve the references for the referential members to perform
operations on their targets.
3.2 Ordered Collections
Requirements 3.2.1 - 3.2.3 in this section push beyond what the
WebDAV base specification provides, requiring standardization on a
single mechanism for ordering collections. The remaining
requirements describe what that standard mechanism must be like.
3.2.1 The ordering mechanism is sufficiently standardized that
different applications and servers can operate on the same
ordering without private agreements.
Applications and servers can find out what orderings are present
and can apply an ordering to a collection's members without
private agreements. They can also modify an ordering, at least
with the help of a human user for semantics (See 3.2.2), without
private agreements.
This is the minimum that is needed to support collaborative
management of an ordered collection, where different authoring
tools might be used by the collaborators. It is also what allows
a different tool to be used to view the collection from the one
that was used to create it. Finally, it is needed in order for
servers to list collection members in order, as required by 3.2.3.
3.2.2 The semantics of an ordering are discoverable.
If someone other than the creator of a collection adds a member to
the collection, that person should be able to determine where it
makes sense to position the new member in any orderings on the
collection.
In some cases it may be possible for the semantics to be expressed
in a machine-usable way. These are likely to be only the cases
where the ordering is based on property values.
3.2.3 When a client requests a listing of the members of a
collection, it can request that a particular ordering be
applied to the response.
Although servers may ignore the request that the member listing be
ordered, defining a request syntax that includes an ordering makes
it possible for servers to free clients from the burden of
applying the ordering to the member listing.
Slein [Page 7]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
3.2.4 It is possible to order the members of a collection in an
arbitrary way, not necessarily based on property values.
A professor may order a collection of course readings in the
sequence that makes sense to coordinate the readings with her
lectures, not based on any property of the member resources.
3.2.5 Internal and referential members may by intermixed in the same
ordering.
The professor in the previous example may store some readings as
internal resources of the collection, but reference others from
servers at another university. Nevertheless, all the readings
need to be included in the ordering for her students' use.
3.2.6 It is possible to impose multiple orderings on the same
collection.
Two instructors may teach different sections of the same course,
and share a collection of readings. They may prefer to assign the
readings in a different order. Then two orderings are needed for
the same collection.
3.2.7 An ordering is not required to contain all members of the
collection.
Two instructors may teach different sections of the same course,
and share a collection of readings. One instructor assigns his
students only a subset of the readings, so his ordering contains
only a subset of the collection members.
3.2.8 A collection member may belong to the same ordering more than
once.
An instructor may like to have her students read a particular
article near the beginning of the course, and re-read it at the
end. She would like the article to appear twice in her ordering
of the collection.
3.2.9 It is possible to modify an existing ordering efficiently.
The implementation of orderings and operations on them should
minimize the number of round trips and the amount of data
transferred when modifying an existing ordering. This includes
cases where a single collection member is inserted into an
ordering or removed from an ordering, as well as cases where many
collection members are moved to different positions in the
ordering.
Slein [Page 8]
INTERNET-DRAFT WebDAV Collection Requirements March 11, 1998
4 Issues
What are we really trying to capture in distinguishing between
internal and referential members? Are there important differences
in functionality that are not captured by these requirements?
What should be our position on passing requests through to the
target of a referential member? Never? Only for certain
operations? Provide an option for all / some operations?
Is there any requirement for unnamed referential members of
collections?
How far should a server be expected to maintain orderings? If a
member is deleted from a collection, should the server delete it
from all orderings? Should a server perform all maintenance on
orderings, with clients operating on them only indirectly by
submitting requests to the server?
5 Acknowledgements
This draft has benefited from thoughtful discussion by Ellis
Cohen, Jim Davis, Daniel LaLiberte, Steve Martin, Surendra Koduru
Reddy, John Turner, Jim Whitehead, and others.
6 References
[Goland et al., 1998] Y. Y. Goland, E. J. Whitehead, Jr., A.
Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed
Authoring on the World Wide Web - WebDAV." Draft-ietf-webdav-
protocol-07. Microsoft, U.C. Irvine, Netscape, Novell. February,
1998.
7 Authors' Addresses
J. Slein
Xerox Corporation
800 Phillips Road
Webster, NY 14580
Email: slein@wrc.xerox.com
Expires September 16, 1998
Slein [Page 9]
