RFC 2291          Distributed Authoring and Versioning     February 1998


5.7. Name Space Manipulation

5.7.1. Copy

5.7.1.1. Functional Requirements

   It must be possible to duplicate a resource without a client loading,
   then resaving the resource. After the copy operation, a modification
   to either resource must not cause a modification to the other.

5.7.1.2. Rationale

   There are many reasons why a resource might need to be duplicated,
   such as changing ownership, preparing for major modifications, or
   making a backup. Due to network costs associated with loading and
   saving a resource, it is far preferable to have a server perform a
   resource copy than a client.

5.7.2. Move/Rename

5.7.2.1. Functional Requirements

   It must be possible to change the location of a resource without a
   client loading, then resaving the resource under a different name.
   After the move operation, it must no longer be possible to access the
   resource at its original location.

5.7.2.2. Rationale

   It is often necessary to change the name of a resource, for example
   due to adoption of a new naming convention, or if a typing error was
   made entering the name originally. Due to network costs, it is
   undesirable to perform this operation by loading, then resaving the
   resource, followed by a delete of the old resource. Similarly, a
   single rename operation is more efficient than a copy followed by a
   delete operation.  Note that moving a resource is considered the same
   function as renaming a resource.

5.8. Collections

   A collection is a resource that is a container for other resources,
   including other collections.  A resource may belong to a collection
   either directly or by reference.  If a resource belongs to a
   collection directly, name space operations like copy, move, and
   delete applied to the collection also apply to the resource.  If a
   resource belongs to a collection by reference, name space operations
   applied to the collection affect only the reference, not the resource
   itself.




 
RFC 2291          Distributed Authoring and Versioning     February 1998


5.8.1. Functional Requirements

   5.8.1.1. List Collection. A listing of all resources in a specific
   collection must be accessible.

   5.8.1.2. Make Collection. It must be possible to create a new
   collection.

   5.8.1.3. Add to Collection.  It must be possible to add a resource to
   a collection directly or by reference.

   5.8.1.4. Remove from Collection.  It must be possible to remove a
   resource from a collection.

5.8.2. Rationale

   In [URL] it states that, "some URL schemes (such as the ftp, http,
   and file schemes) contain names that can be considered hierarchical."
   Especially for HTTP servers which directly map all or part of their
   URL name space into a filesystem, it is very useful to get a listing
   of all resources located at a particular hierarchy level. This
   functionality supports "Save As..." dialog boxes, which provide a
   listing of the entities at a current hierarchy level, and allow
   navigation through the hierarchy. It also supports the creation of
   graphical visualizations (typically as a network) of the hypertext
   structure among the entities at a hierarchy level, or set of levels.
   It also supports a tree visualization of the entities and their
   hierarchy levels.

   In addition, document management systems may want to make their
   documents accessible through the Web.  They typically allow the
   organization of documents into collections, and so also want their
   users to be able to view the collection hierarchy through the Web.

   There are many instances where there is not a strong correlation