Initial Dist. Auth. Requirements

Here is my initial draft of requirements that should be present in
HTTP to support distributed authoring.  The intent is to only discuss
distributed authoring requirements in this document, and to not
discuss versioning requirements, as much as this is possible (locking,
edit notification, and relationships are overlapping issues, though.)

I've posted this to both the versioning and distributed authoring lists,
but my intent is to have discussion take place on the distributed authoring
list (<w3c-dist-auth-request@w3.org> to join).

I'm hoping to be able to package this up in IETF standard format and
send it off for comment by the HTTP WG later next week.

Many thanks to Yaron Goland, David Durand, Fabio Vitali, Christopher
Seiwald, and Judith Slein for their ifnromative posts which really
helped clarify and provide rationale for these requirements.

- Jim


Requirements on HTTP for Distributed Editing

Jim Whitehead, U.C. Irvine, <ejw@ics.uci.edu>
Rev. 0.1, August 29, 1996

Abstract

TBD.

1.0 INTRODUCTION

This document describes functionality which, if provided in the HyperText
Transfer Protocol (HTTP) Specification [Ref HTTP/1.1 Spec.], would support
the interoperability of tools which allow remote loading, editing and saving
(publishing) of various media types using HTTP. As much as possible, this
functionality is described without suggesting a proposed implementation,
since in general, there are many ways to perform the functionality within
the HTTP framework.

Much of the functionality described in this document stems from the
assumption that people performing distributed authoring only have access to
the objects they are editing via the HTTP protocol. This is in contrast to
the majority of current authoring practice, where there is access to the
underlying storage media, often via a shell or graphical user interface to a
filesystem. Authors need more than just remote control over their individual
documents: they need remote control over the namespace in which those
documents reside. Currently, authors control their namespace by interacting
directly with the underlying storage system, but when performing distributed
authoring this access is not available.

2.0 REQUIREMENTS

In the requirement descriptions below, the requirement will be stated,
followed by its rationale. If any current distributed authoring tools
currently implement the requirement, this is also mentioned. It is assumed
that "server" means "a program which receives and responds to HTTP
requests," and that "distributed authoring tool" or "intranet enabled tool"
means "a program which can retrieve a source entity via HTTP, allow editing
of this entity, and then save/publish this entity to a server using HTTP." A
"client" is "a program which issues HTTP requests and accepts responses."

  1. Source Retrieval. The source of any given entity should be retrievable
     via HTTP.

     There are many cases where the source entity stored on a server does
     not correspond to the actual entity transmitted in response to an HTTP
     GET. Current known cases are server side include directives, and SGML
     which is converted on the fly to HTML. There are many possible cases,
     such as automatic conversion of bitmap images into several variant
     bitmap media types (e.g. GIF, JPEG), and automatic conversion of an
     application's native media type into HTML. As an example of this last
     case, a word processor could store its native media type on a server
     which automatically converts it to HTML. A GET of this entity would
     retrieve the HTML. Retrieving the source of this entity would retrieve
     the word processor native entity.

  2. Locks. It should be possible, via HTTP, to restrict modification of an
     entity to a specific person, or list of persons. It should be possible
     to query for whether a given URL has any active modification
     restrictions, and if so, who currently has modification permission.
  3. Independence of locks. It should be possible to lock an entity without
     re-reading the entity, and without commiting to editing an entity.

     At present, HTTP does not provide any support for preventing two or
     more people from overwriting each other's modifications when they save
     to a given URL. Furthermore, there is no way for people to discover if
     someone else is currently making modifications to an entity. 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. Furthermore, locking support is also a key
     component of many versioning schemes, a desirable capability for
     distributed authoring.

     An author may wish to lock an entire web of entities even though they
     are editing just a single entity, just to keep the other entities from
     changing. In this way, an author can ensure that if a local hypertext
     web is consistent in their distributed authoring tool, it will then be
     consistent when they write it to the server. Because of this, it should
     be possible to take out a lock without also causing transmission of the
     contents of an entity. Similarly, it should not be assumed that because
     an entity is locked, that it will necessarily be modified.

  4. Notification of Intention to Edit. It should be possible to notify the
     HTTP server that an entity is about to be edited by a given person. It
     should be possible to query the HTTP server for the list of people who
     have notified the server of their intent to edit an entity.

     Experience from configuration management systems has shown that people
     need to know when they are about to enter a parallel editing situation.
     Once notified, they either decide not to edit in parallel with the
     other authors, or they use out-of-band communication (face-to-face,
     telephone, etc.) to coordinate their editing to minimize the difficulty
     of merging their results. Notification is separate from locking, since
     a lock does not necesssarily imply an entity will be edited, and a
     notification of intention to edit does not carry with it any access
     restrictions. This capability is supportive of versioning, since a
     check-out is typically involves taking out a lock, making a
     notification of intention to edit, and getting the entity to be edited.

  5. Relationships. Via HTTP, it should be possible to create, query, and
     delete arbitrary typed relationships (links) between entities of any
     media type.

     Relationships (or links which are not necessarily navigable) between
     entities can be used for many purposes. Relationships support
     pushbutton printing of a multi-resource document in a prescribed order,
     jumping to the access control page for an entity, and quick browsing of
     related information, such as a table of contents, an index, a glossary,
     help pages, etc. While relationship support is provided by the HTML
     "LINK" element, this is limited only to HTML entities, and does not
     support bitmap image types, and other non-HTML media types.
     AOLpress, America Online, currently "allows pages to add toolbar
     buttons on the fly using the HTML 3.2 <LINK REL....> tag. For example,
     your page can add toolbar buttons that link to a home page, table of
     contents, index, glossary, copyright page, next page, previous page,
     help page, higher level page, or a bookmark in the document." (Source:
     http://www.aolpress.com/press/1.2features.html)

  6. Attributes. Via HTTP, it should be possible to create, query, and
     delete arbitrary attributes on entities of any media type.

     Attributes can be used to define fields (such as author, title,
     subject, organization) on resources of any media type, which can be
     used later in searches. Attributes also support the creation of catalog
     entries as a placeholder for an entity which are not available in
     electronic form, or which will be available later.

  7. List URL Hierarchy Level. A listing of all entities, along with their
     media type, and last modified date, which are located at a specific URL
     [ref RFC 1738] hierarchy level in an http URL scheme should be
     accessible via HTTP.

     In [ref RFC 1738] 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.
     AOLpress, America Online, currently supports "Save As..." dialog boxes,
     and graphical network visualization of a portion of a site's hypertext
     structure, which they term a "mini-web."
     FrontPage, Microsoft, also currently supports a graphical network
     visualization and additionally support a tree visualization of a
     portion of a site's structure.

  8. Make URL Hierarchy Level. Via HTTP, it should be possible to create a
     new URL hierarchy level in an http URL scheme.

     The ability to create containers to hold related entities supports
     management of a name space by packaging its members into small, related
     clusters. This utility of this capability is demonstrated by its wide
     implementation in recent operating systems. The ability to create a URL
     hierarchy level also supports the creation of "Save As..." dialog boxes
     with "New Level/Folder/Directory" capability, common in many
     applications.
     AOLpress, America Online, currently supports this capability through
     their "Save As..." dialog box, and their custom MKDIR method.

  9. Copy. Via HTTP, it should be possible to make a byte-for-byte duplicate
     of an entity without a client loading, then resaving the entity. This
     copy should leave an audit trail.

     There are many reasons why an entity might need to be duplicated, such
     as change of ownership, a precursor to major modifications, or to make
     a backup. In combination with delete functionality, copy can be used to
     implement rename and move capabilities, by performing a copy to a new
     name, and a delete of the old name. Due to network costs associated
     with loading and saving an entity, it is far preferable to have a
     server perform an entity copy than a client. If a copied entity records
     which entity it is a copy of, then it would be possible for a cache to
     avoid loading the copied entity if it already locally stores the
     original.

 10. Rename. Via HTTP, it should be possible to change the URL of an entity
     without a client loading, then resaving the entity under a different
     name.

     It is often necessary to change the name of an entity, 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 entity,
     followed by a delete of the old entity. Ideally an HTTP server should
     record the rename operation, and issue a "301 Moved Permanently" status
     code for requests on the old URL. Note that moving an entity is
     considered the same function as renaming an entity.


--#--

Received on Thursday, 29 August 1996 17:05:39 UTC