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

RE: Ordered Collections

From: Judith Slein <slein@wrc.xerox.com>
Date: Mon, 11 May 1998 14:50:09 PDT
Message-Id: <3.0.3.32.19980511175009.00970cc0@pop-server.wrc.xerox.com>
To: ejw@ics.uci.edu
Cc: w3c-dist-auth@w3.org
Thanks to those who have provided comments on the advanced collections
requirements.  I've revised the requirements based on those comments.
Here's how they look at the moment.  Unless I hear protests by close of
business Wednesday May 13, this is what I will submit to the Internet
Drafts directory this week.  I'm expecting that this draft will be the
basis for discussion in Seattle in June.

--Judy

-----------------------


     WEBDAV Working Group                                          J. Slein
     INTERNET DRAFT                                       Xerox Corporation
     <draft-ietf-webdav-collection-reqts-01>                   May 15, 1998
     Expires Novermber 15, 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.

        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 integrity is guaranteed by the server

        Weak Reference
           A reference whose 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
        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.  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.

        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
        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

        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
        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.

        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
        deleting the referential memberís 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 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 with 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 choose intelligently its own strategy for working with
        referential members.  For example, if a client does not know
        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.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 collectionís 
        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.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.

        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
        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.3  When a client requests a listing of the members of a
            collection, it can request that the collection ordering be
            applied to the response.  The server may decline to support
            the request for an ordered 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.

     3.2.4  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 
        "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.5  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.

     3.2.6  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.

     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 15, 1998

Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm
Received on Monday, 11 May 1998 17:52:04 GMT

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