WEBDAV Working Group J. Slein
INTERNET DRAFT Xerox Corporation
<draft-ietf-webdav-collection-reqts-01> May 20, 1998
Expires November 20, 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), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),munnari.oz.au
(Pacific Rim), ftp.ietf.org (US EastCoast), 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.
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.
Slein Page 1
INTERNET-DRAFT WebDAV Collection Requirements May 1998
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
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
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.
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
Slein Page 2
INTERNET-DRAFT WebDAV Collection Requirements May 1998
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 companys
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
For many applications, it is useful 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
authors last name, or one from most recent to oldest last-
modified-date. An ordering need not be based on property values,
however. A professor may order a collection of course readings in
the sequence that makes sense to coordinate them with her lectures,
where there is no property on the member resources that could be
used to create this ordering. This set of requirements is
primarily concerned with orderings that are not based on property
values.
Another useful distinction is between server-maintained and
client-maintained orderings. In server-maintained orderings, the
server enforced the semantics of the ordering by placing each
collection member at the appropriate position in the ordering;
clients cannot alter the ordering. In client-maintained orderings,
the client places each collection member in the ordering based on
its understanding of the semantics of the ordering; the server
does nothing to validate the client's positioning of the member
in the ordering. This set of requirements is concerned only with
client-maintained orderings.
WebDAV already provides tools that could be used for creating and
maintaining ordered collections. For example, using only the base
WebDAV specification, an application could create a WebDAV property
called "Order" on a collection 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
Slein Page 3
INTERNET-DRAFT WebDAV Collection Requirements May 1998
the same collection without private agreements about how to manage
and examine its order. To make this possible, there needs to be a
standard way to manipulate and retrieve 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
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
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.
Slein Page 4
INTERNET-DRAFT WebDAV Collection Requirements May 1998
Passing operations through to the target resource would expose
servers to the risks of circular references and long chains of
references that refer to other references.
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.
Requirement 3.1.6 makes it unnecessary for the server to pass
operations through to the target resource. The client can always
obtain the URI of the target resource and operate directly on the
target.
3.1.5 Operations on a resource do not affect weak references to them.
This requirement is the mirror of 3.1.4. Just as we do not expect
operations on a reference to affect its target, so we do not expect
operations on a target to affect references to it. Locking a
target does not cause the references to it to be locked. Modifying
the properties of a target does not cause changes in the properties
of references to it. Etc.
Just as in 3.1.4 passing operations through to the target can be
problematic, so here reflecting operations back to the referencing
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.
The requirement cannot apply to all referential members, however.
Section 1 defined weak references and strong references. Strong
references are those whose referential integrity is guaranteed by
the server. Weak references are those whose referential integrity
is not guaranteed by the server. For strong references, some
operations on targets must cause changes in references to them. For
strong references, if the target is moved, the reference must
change to reflect the new location of the target, for example.
Requirement 3.1.11 makes it possible that some servers will support
strong references. Consequently, the requirement cannot apply to
all referential members, but only to weak references.
3.1.6 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.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.
It is important to note that this is a different operation from
Slein Page 5
INTERNET-DRAFT WebDAV Collection Requirements May 1998
deleting the referential members target resource. According to
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.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.
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.10 A listing of the members of a collection shows both the
internal members and the referential members.
A listing of collection members with Depth = 1 or Depth = infinity
shows all members of the collection, whether internal or external.
If Depth = infinity, however, the listing will not follow
references into any collections to which they may refer. This is
to avoid the risk of being caught in a circle of references.
3.1.11 It is possible to request creation of a referential member that
the server will guarantee to have referential integrity.
For some applications, broken references are unacceptable.
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. For applications that require
referential integrity, it must be possible to specify in a
request for creation of a referential member that its integrity
be guaranteed. If the server cannot honor this request, it must
decline to create the referential member. A referential member
whose integrity is guaranteed by the server is called a strong
reference.
3.1.12 For any member of a collection, it is possible to discover
whether it is an internal or a referential member.
Since 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.1.13 It is possible to discover whether a referential member is a
strong reference or a weak reference.
Knowing whether a referential member is strong or weak allows a
client to intelligently choose its own strategy for working with
referential members. For example, if a client does not know
Slein Page 6
INTERNET-DRAFT WebDAV Collection Requirements May 1998
whether a particular reference is strong or weak, it may choose to
recreate that referential member to be sure of referential
integrity; but if it knows that the reference is strong, it will
not bother to do this.
3.1.14 It is possible to discover whether a resource is the target of
a strong reference.
This requirement insures that both ends of a referential integrity
relationship have the same information available.
3.1.15 A referential member of a collection is itself a resource.
This makes explicit what is suggested by several of the preceding
requirements. Requirement 3.1.9 in particular, that referential
members carry their own properties, forces referential members to
be resources. WebDAV properties can belong only to resources.
3.2 Ordered Collections
3.2.1 Ordering is sufficiently standardized that different
applications and servers can operate on the same ordering
without private agreements.
Applications and servers can apply an ordering to a collections
members or discover the ordering of 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.3), 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.6.
3.2.2 A collection is not required to be ordered.
A WebDAV server may support collections without supporting ordered
collections. Even if the server supports ordered collections,
there is no requirement that every collection on that server be
ordered. Since these requirements concern only client-maintained
orderings, clients will decide whether any given collection is
ordered.
The remaining requirements apply only to collections that are
ordered.
3.2.3 The semantics of an ordering are discoverable.
The semantics of an ordering is the principle or rule according to
which the collection members are ordered. This principle must be
discoverable if someone (or some application) other than the one
that created a collection is to be able to add a member to it and
Slein Page 7
INTERNET-DRAFT WebDAV Collection Requirements May 1998
determine where it makes sense to position the new member in the
collection's ordering.
In some cases it may be possible for the semantics to be expressed
in a machine-usable way, so that an application could automatically
position a new member in the ordering. In other cases the
semantics may require a human user to apply them. In either case
they should be discoverable.
3.2.4 Each collection member must appear in the ordering exactly
once.
It would be possible to support orderings that contain only a
subset of the collection members, or orderings that can contain
a single collection member more than once. It is not necessary,
however, since the same result can be achieved by creating a
new collection with exactly the desired members, and including
each member of the new collection in its ordering exactly once.
This requirement implies that the server will check, whenever a
member is added to an ordering, to make sure that it is not already
in the ordering. It also implies that either the protocol itself
or the server will insure that whenever a new member is added to
a collection, it is also added to the collection ordering.
3.2.5 An ordering must not include any resources that are not members
of the collection.
The server must insure that when a member is removed from a
collection, it is also removed from the collection's ordering.
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 requirement frees clients from the burden of applying the
ordering to the member listing.
3.2.7 It is possible to order the members of a collection in a
client-specified way, not necessarily based on property values.
Orderings that are based on property values can be obtained by a
search protocol that supports sorted result sets. This set of
requirements is not concerned with such orderings. It is intended
primarily to support orderings that cannot be obtained by sorting
on property values.
A property is not always available that can serve as the basis for
a desired ordering. For example, a professor may wish to order a
collection of course readings in the sequence that makes sense to
coordinate the readings with her lectures. But the properties of
resources at the Web site are standardized and do not include one
that is appropriate to use for this purpose.
Even if the professor in the example could create a
Slein Page 8
INTERNET-DRAFT WebDAV Collection Requirements May 1998
"sequencenumber" property to use in sorting the collection, this
strategy would be undesirable unless she knew she would not be
adding any readings or changing the order of her lectures once the
values of sequencenumber were set. Inserting a new reading into
the sequence would require updating the sequencenumber property of
each reading that comes after the new one in the sequence. Ordered
collections are intended to support this sort of case, where
sorting based on a property value is impossible or inefficient.
3.2.8 Internal and referential members may be 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.
4 Acknowledgements
This draft has benefited from thoughtful discussion by Steve
Carter, Ellis Cohen, Jim Davis, Spencer Dawkins, Yaron Goland,
Alex Hopmann, Rohit Khare, Daniel LaLiberte, Steve Martin,
Surendra Koduru Reddy, Nick Shelness, John Turner, Jim Whitehead,
and others.
5 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-08. Microsoft, U.C. Irvine, Netscape, Novell. April,
1998.
6 Authors' Addresses
J. Slein
Xerox Corporation
800 Phillips Road
Webster, NY 14580
Email: slein@wrc.xerox.com
Expires November 20, 1998
Slein Page 9
Datatracker
Report a datatracker bug
draft-ietf-webdav-collection-reqts-01
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |