Jim Davis' slides

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)
   jdavis@parc.xerox.com

2. Overview
* Requirements Internet Draft

http://www.ics.uci.edu/~ejw/authoring/collection/draft-ietf-webdav-collectio
n-reqts-00.txt
  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
agreements

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


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

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

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

    * 3.2.9 It is possible to modify an existing ordering efficiently.

Received on Friday, 3 April 1998 18:01:30 UTC