5.1.1. Functional Requirements

   It must be possible to create, modify, read and delete arbitrary
   properties on resources of any media type.

5.1.2. Rationale

   Properties describe resources of any media type.  They may include
   bibliographic information such as author, title, publisher, and
   subject, constraints on usage, PICS ratings, etc. These properties
   have many uses, such as supporting searches on property values,
   enforcing copyrights, and the creation of catalog entries as
   placeholders for objects which are not available in electronic form,
   or which will be available later.

5.2. Links

5.2.1. Functional Requirements

   It must be possible to create, modify, read and delete typed links
   between resources of any media type.

5.2.2. Rationale

   One type of link between resources is the hypertext link, which is
   browsable using a hypertext style point-and-click user interface.
   Links, whether they are browsable hypertext links, or simply a means
   of capturing a relationship between resources, have many purposes.
   Links can support pushbutton printing of a multi-resource document in
   a prescribed order, jumping to the access control page for a
   resource, and quick browsing of related information, such as a table






 
RFC 2291          Distributed Authoring and Versioning     February 1998


   of contents, an index, a glossary, a bibliographic record, help
   pages, etc. While link support is provided by the HTML "LINK"
   element, this is limited only to HTML resources [HTML]. Similar
   support is needed for bitmap image types, and other non-HTML media
   types.

5.3. Locking

5.3.1. General Principles

   5.3.1.1. Independence of locks. It must be possible to lock a
   resource without performing an additional retrieval of the resource,
   and without committing to editing the resource.

   5.3.1.2. Multi-Resource Locking. It must be possible to take out a
   lock on multiple resources residing on the same server in a single
   action, and this locking operation must be atomic across these
   resources.

5.3.2. Functional Requirements

   5.3.2.1. Write Locks. It must be possible to restrict modification of
   a resource to a specific person.

   5.3.2.2. Lock Query. It must be possible to find out whether a given
   resource has any active locks, and if so, who holds those locks.

   5.3.2.3. Unlock. It must be possible to remove a lock.

5.3.3. Rationale

   At present, the Web provides limited support for preventing two or
   more people from overwriting each other's modifications when they
   save to a given URI. Furthermore, there is no way to discover whether
   someone else is currently making modifications to a resource. This is
   known as the "lost update problem," or the "overwrite problem." Since
   there can be significant cost associated with discovering and
   repairing lost modifications, preventing this problem is crucial for
   supporting distributed authoring. A write lock ensures that only one
   person may modify a resource, preventing overwrites. Furthermore,
   locking support is a key component of many versioning schemes, a
   desirable capability for distributed authoring.

   An author may wish to lock an entire web of resources even though he
   is editing just a single resource, to keep the other resources from
   changing. In this way, an author can ensure that if a local hypertext
   web is consistent in his distributed authoring tool, it will then be





 
RFC 2291          Distributed Authoring and Versioning     February 1998


   consistent when he writes it to the server. Because of this, it
   should be possible to take out a lock without also causing
   transmission of the contents of a resource.