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

Jim Davis' slides

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Fri, 3 Apr 1998 14:13:24 -0800
Message-ID: <01BD5F0A.AB2FF340.ejw@ics.uci.edu>
To: "'WEBDAV WG'" <w3c-dist-auth@w3.org>
Here is a text version of the slides Jim Davis presented at the WebDAV meeting yesterday.

1. Requirements for Advanced Collection Functionality in WebDAV
   Jim Davis (on behalf of Judith Slein, author)

2. Overview
* Requirements Internet Draft

  Judith Slein, author
    * Discussion DL: w3c-dist-auth@w3.org
    * Email archive: http://lists.w3.org/Archives/Public/w3c-dist-auth/

3. Goals
    * concensus on requirements
    * or at least shared understanding of them
    * no design proposals

4. Outline
    * rationale
    * terminology
    * requirements for referential members
    * requirements for ordering

5. Rationale
    * Enable shared resources
    * Enable applications to see a consistent ordering without private

6. Terminology
    * Collection
    * Member Resource
    * Referential Member Resource
      has no content, is a reference to another resource
      (as opposed to 'external' member)
    * Internal Member Resource
      any member that is not a reference
    * Target Resource

7-11. Requirements for Referential Members
    * 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.

    * 3.1.4 Operations on a referential member do not affect the resource
it references.
     they are distinct resources
     otherwise, security is problematic

    * 3.1.5 For any referential member of a collection, it is possible to
obtain the URI of the resource it references.
allows client to affect target

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

    * 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.
e.g. "who added"

    * 3.1.9 A referential member of a collection also inherits the
properties of the resource it refers to.
     so that referential members look like internal members
     an exception to 3.1.4

    * 3.1.10 A listing of the members of a collection shows both the
internal members and the referential members.
11. referential members continued

    * 3.1.11 Servers are encouraged to maintain referential integrity for
referential members as far as possible, but are 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.

12. Requirements for Ordered Collections

    * 3.2.1 The ordering mechanism is sufficiently standardized that
different applications and servers can operate on the same ordering without
private agreement.

    * 3.2.2 The semantics of an ordering are discoverable.

    * 3.2.3 When a client requests a listing of the members of a
collection, it can specify the ordering to be applied, and the server will
apply that ordering to its response.

    * 3.2.4 It is possible to order the members of a collection in an
arbitrary way, not necessarily based on property values.

    * 3.2.5 Internal and referential members may by intermixed in the same

    * 3.2.6 It is possible to impose multiple orderings on the same

    * 3.2.7 An ordering is not required to contain all members of the

    * 3.2.8 A collection member may belong to the same ordering more than

    * 3.2.9 It is possible to modify an existing ordering efficiently.
Received on Friday, 3 April 1998 18:01:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC