- From: Judith Slein <slein@wrc.xerox.com>
- Date: Mon, 10 Feb 1997 11:23:55 PST
- To: w3c-dist-auth@w3.org
Here is a draft of a merged requirements document. I tried not to make many substantive changes, since we seemed to have consensus on the content of the two original papers. Fabio Vitali provided lots of help and good advice in merging the two papers, although I did not follow his advice on all points. Comments from Fabio and me are marked *** in this draft. I have tried to mark points that conflict with the current specification or that seem to be subjects of controversy within the group. Please review this document and provide comments. If we are to meet our schedule, which calls for the requirements to be an Internet Draft by the end of February, we need to try to resolve outstanding issues by February 24. I'm also sending out a separate mailnote that summarizes what I take to be the areas where the requirements and the specification are in conflict, and areas that are controversial. Thanks for your help. --Judy -------------------------- WEBDAV Working Group J.A. Slein INTERNET-DRAFT Xerox Corporation < > E.J. Whitehead, Jr. U.C. Irvine D.G. Durand Boston University F. Vitali University of Bologna February 1997 Expires August 1997 Requirements on HTTP for Distributed Authoring and Versioning Status of this Memo This document is an Internet draft. Internet drafts are working documents of the Internet Engineering Task Force (IETF), its areas and its working groups. Note that other groups may also distribute working information as Internet drafts. Internet Drafts are draft documents valid for a maximum of six months and can be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use Internet drafts as reference material or to cite them as other than as "work in progress". To learn the current status of any Internet draft please check the "lid-abstracts.txt" listing contained in the Internet drafts shadow directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or ftp.isi.edu (US West coast). Further information about the IETF can be found at URL: http://www.ietf.org/ Distribution of this document is unlimited. Please send comments to the WWW Distributed Authoring and Versioning mailing list, <w3c-dist-auth@w3.org>, which may be joined by sending a message with subject "subscribe" to <w3c-dist-auth-request@w3.org>. Discussions are archived at URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/. The HTTP working group at <http-wg@cuckoo.hpl.hp.com> also discusses the HTTP protocol. Discussions of the HTTP working group are archived at URL: http://www.ics.uci.edu/pub/ietf/http/. General discussions about HTTP and the applications which use HTTP should take place on the <www-talk@w3.org> mailing list. Abstract The HyperText Transfer Protocol, version 1.1 (HTTP/1.1), provides simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of HTTP/1.1 have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve relationship management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. 1. Introduction This document describes functionality which, if provided in the HyperText Transfer Protocol (HTTP) [4], 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 there are many ways to perform the functionality within the HTTP framework. It is also possible that a single mechanism within HTTP could simultaneously satisfy several requirements. ***Fabio - Many of the versioning requirements call for extensions to URLs, not to HTTP. ***Judy - There is controversy in the group about whether we should be extending HTTP or defining a separate protocol. 2. Rationale The HTTP protocol contains functionality which enables the editing of web content at a remote location, without direct access to the storage media via an operating system. This capability is exploited by several existing HTML distributed authoring tools, and by a growing number of mainstream applications (e.g. word processors) which allow users to write (publish) their work to an HTTP server. To date, experience from the HTML authoring tools has shown they are unable to meet their users' needs using the facilities of the HTTP protocol. The consequence of this is either postponed introduction of distributed authoring capability, or the addition of nonstandard extensions to the HTTP protocol. These extensions, developed in isolation, are not interoperable. Other authoring applications have wanted to access document repositories or version control systems through Web gateways, and have been similarly frustrated. Where this access is available at all, it is through nonstandard extensions to HTTP that force clients to use a different interface for each vendor's service. This document describes requirements for a set of standard extensions to HTTP that would allow distributed Web authoring tools to provide the functionality their users need by means of the same standard syntax across all compliant servers. The broad categories of functionality that need to be standardized are: Attributes Relationships Locking Notification of Intent to Edit Retrieval of Unprocessed Source for Editing Partial Write Name Space Manipulation Collections Versioning 3. General Principles This section describes a set of general principles that the HTTP extensions should follow. These principles cut across categories of functionality. 3.1. User Agent Interoperability All clients should be able to work with any WebDAV-compliant HTTP server. It is acceptable for some client/server combinations to provide special features that are not universally available, but the protocol should be sufficient that a basic level of functionality will be universal. It should be possible for servers and clients to negotiate the use of optional features. 3.2. Legacy Client Support WebDAV-compliant servers should be able to interoperate with non-WebDAV clients. 3.3. Data Format Compatibility. WebDAV-compliant servers should be able to work with existing resources and URLs. Special additional information should not become a mandatory part of document formats. 3.4. HTTP Compatibility (new) Our aim is to make extended authoring capabilities available through HTTP. In extending HTTP, we are obligated to follow its design conventions and stay within its spirit. This means, for example, that methods should operate only on resources. It means that parameters should be communicated in headers. These and other conventions should be observed in the design of the extensions. 3.5. Replicated, Distributed Systems (new) Distribution and replication are at the heart of the Internet. All WebDAV extensions should be designed to allow for distribution and replication. Version trees should be able to be split across multiple servers. Collections may have members on different servers. Resources may have attributes on different servers. Any resources may be cached or replicated for mobile computing or other reasons. Consequently, we must keep these issues in mind through all our design efforts. 4. Requirements In the requirement descriptions below, the requirement will be stated, followed by its rationale. If any 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." (Get rid of references to current tools altogether, or do more thorough research.) 4.1. Attributes Via HTTP, it should be possible to create, modify, query, read and delete arbitrary attributes on resources of any media type. ***Judy - Query is not supported in the specification. Attributes can be used to define fields such as author, title, subject, and organization, on resources of any media type. These attributes have many uses, such as supporting searches on attribute contents, and the creation of catalog entries as a placeholder for an object which is not available in electronic form, or which will be available later. 4.2. Relationships Via HTTP, it should be possible to create, query, and delete typed relationships between resources of any media type. A hypertext link is a relationship between resources which is browsable using a hypertext style point-and-click user interface. Relationships, whether they are browsable hypertext links, or simply a means of capturing a interrelation between resources, have many purposes. Relationships can support pushbutton printing of a multi-resource document in a prescribed order, jumping to the access control page for an resource, 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 resources, and does not support bitmap image types, and other non-HTML media types. AOLpress from America Online [1] 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." ***Fabio - The definition of locking here conflicts with the one that was used in the versioning requirements paper. More in a separate mail note. 4.3. Locking 4.3.1. General Principles 4.3.1.1. Independence of locks. It should be possible to lock a resource without re-reading the resource, and without committing to editing the resource. 4.3.1.2. Multi-Resource Locking. It should be possible to take out a lock on multiple resources in the same action, and this locking operation must be atomic across these resources. ***Judy - Multi-resource locking is not in the specification 4.3.1.3. Partial-Resource Locking. It should be possible to take out a lock on subsections of an resource. ***Judy - Controversy on this issue at Irvine. 4.3.1.4. Multi-Person Locking. It should be possible to assign a lock to a single person or to multiple persons with a single action. ***Judy - Multi-person locking is not in the specification. ***Fabio - Add a statement that support for locking is optional. Also say that systems that do not support locking should provide some other type of consistency management. 4.3.2. Functional Requirements 4.3.2.1. Write Locks. It should be possible, via HTTP, to restrict modification of a resource to a specific person, or list of persons. ***Fabio - The definition of a write lock should be this: A write lock states that no consistency problem will ever occur by changing the resource, not that no one else is allowed access to that resource. On the other hand, it can be said that access rights to successfully Unlocked resources should be allowed to all authorized users. 4.3.2.2. Read Locks. It should be possible, via HTTP, to indicate to the HTTP server that the contents of a resource should not be modified until the read lock is released. ***Judy - Read locks are not in the specification. 4.3.2.3. Lock Query. It should be possible to query for whether a given URL has any active modification restrictions, and if so, who currently has modification permission. ***Judy - Should add Unlock. 4.3.3. Rationale At present, HTTP provides limited 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 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 (or list of persons) may modify a resource, preventing overwrites. 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 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 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. Since it should not be assumed that because a resource is locked, that it will necessarily be modified, and since many people may wish to have simultaneous guarantees that a resource will not be modified, but still not want to modify the resource themselves, it is desirable to have a "read" lock capability. A read lock, by being less restrictive, provides better support than a write lock for providing a guarantee that a resource will not be modified. Put differently, a read lock states that the resource is guaranteed not to change for the duration of the lock. A write lock states that a resource is guaranteed not to change only if the owner of the lock does not change it, and only the owner of the lock may change it. It is often necessary to guarantee that a lock or unlock operation occurs at the same time across multiple resources, a feature which is supported by the multiple-resource locking requirement. This is useful for preventing a collision between two people trying to establish locks on the same set of resources, since with multi-resource locking, one of the two people will get a lock. If this same multiple-resource locking scenario was repeated by using atomic lock operations iterated across the resources, the result would be a splitting of the locks between the two people, based on resource ordering and race conditions. Partial resource locking provides support for collaborative editing applications, where multiple users may be editing the same resource simultaneously. Partial resource locking also allows multiple people to simultaneously work on a database type resource. 4.4. Notification of Intention to Edit. It should be possible to notify the HTTP server that a resource 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 a resource. ***Judy - It should be possible to notify the server that one no longer intends to edit the resource. ***Judy - Support for notification of intent to edit is found in the specification only in the context of version management. The specification does not allow such notification for non-versioned resources. 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 write lock does not necessarily imply a resource 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 typically involves taking out a write lock, making a notification of intention to edit, and getting the resource to be edited. 4.5. Retrieval of Unprocessed Source for Editing The source of any given entity should be retrievable via HTTP. ***Judy - Not in the specification. There are many cases where the source 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 Standard Generalized Markup Language (SGML) source which is converted on the fly to HyperText Markup Language (HTML) [2] output entities. 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 resource would retrieve the HTML. Retrieving the source would retrieve the word processor native format. This requirement should be met by a general mechanism which can handle both the "single-step" source processing described above, where the source is converted into the transmission entity via a single conversion step, as well as "multi-step" source processing, where there are one or more intermediary processing steps and outputs. An example of multi-step source processing is the relationship between an executable binary image, its object files, and its source language files. It should be noted that the relationship between source and transmission entity could be expressed using the relationship functionality described above in "4.2. Relationships." 4.6. Partial Write. After editing a resource, it should be possible, via HTTP, to write only the changes to the resource, rather than retransmitting the entire resource. ***Judy - Not in the specification. During distributed editing which occurs over wide geographic separations and/or over low bandwidth connections, it would be extremely inefficient (and frustrating) to rewrite a large resource after minor changes, such as a one-character spelling correction. Ideally, support will be provided for transmitting "insert" (e.g., add this sentence in the middle of a document) and "delete" (e.g. remove this paragraph from the middle of a document) style updates. Support for partial resource updates will make small edits more efficient, and allow distributed authoring tools to scale up for editing of large documents. 4.7. Name Space Manipulation ***Fabio - A general treatment of server's name space management from clients should be introduced here. ***Judy - Need more details of the semantics of copy and move, especially for collections, versioned resources, and resources with attributes. ***Judy - In the specification, but not mentioned here: Destroy, Undelete, CopyHead, MoveHead. 4.7.1. Copy. Via HTTP, it should be possible to make a byte-for-byte duplicate of a resource without a client loading, then resaving the resource. This copy should leave an audit trail. There are many reasons why a resource 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 a resource, it is far preferable to have a server perform a resource copy than a client. If a copied resource records which resource it is a copy of, then it would be possible for a cache to avoid loading the copied resource if it already locally stores the original. 4.7.2. Move/Rename. Via HTTP, it should be possible to change the URL of a resource without a client loading, then resaving the resource under a different name. 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. Ideally an HTTP server should record the move operation, and issue a "301 Moved Permanently" status code for requests on the old URL. A move operation, if implemented with attribute support, should also preserve most attributes across a move. Note that moving a resource is considered the same function as renaming a resource. 4.8. Collections 4.8.1. List Collection. A listing of all resources, along with their media type, and last modified date, which are located in a specific collection should be accessible via HTTP. ***Judy - Not in the specification. In [3] 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 HTTP. They typically allow the organization of documents into collections, and so also want their users to be able to view the collection hierarchy through HTTP. There are many instances where there is not a strong correlation between a URL hierarchy level and the notion of a collection. One example is a server in which the URL hierarchy level maps to a computational process which performs some resolution on the name. In this case, the contents of the URL hierarchy level can vary depending on the input to the computation, and the number of resources accessible via the computation can be very large. It does not make sense to implement a directory feature for such a namespace. However, the utility of listing the contents of those URL hierarchy levels which do correspond to collections, such as the large number of HTTP servers which map their namespace to a filesystem, argue for the inclusion of this capability, despite not being meaningful in all cases. If listing the contents of a URL hierarchy level does not makes sense for a particular URL, then a "405 Method Not Allowed" status code could be issued. AOLpress from 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 from Microsoft [6] also currently supports a graphical network visualization and additionally supports a tree visualization of a portion of a site's structure. 4.8.2. Make Collection. Via HTTP, it should be possible to create a new collection. The ability to create collections to hold related resources supports management of a name space by packaging its members into small, related clusters. The utility of this capability is demonstrated by the broad implementation of directories in recent operating systems. The ability to create a collection also supports the creation of "Save As..." dialog boxes with "New Level/Folder/Directory" capability, common in many applications. AOLpress from America Online currently supports this capability through their "Save As..." dialog box, and their custom MKDIR method. 4.9. Versioning In the following discussion, "versioned resource" means a resource that has the structure of a directed acyclic graph, each node of which is a version. "Version" means a node in this structure, which is itself a resource. Each version typically stands in a "derived from" relationship to its predecessor(s). ***Judy - new definitions 4.9.1. General Principles 4.9.1.1. Stableness of versions. Most versioning systems are intended to provide an accurate record of the history of evolution of a document. This accuracy is ensured by the fact that a version eventually becomes "frozen" and immutable. Once a version is frozen, further changes will create new versions rather than modifying the original. In order for caching and persistent references to be properly maintained, a client must be able to determine that a version has been frozen. We require that unlocked resource versions be frozen. This enables the common practice of keeping unfrozen "working versions". Any successful attempt to retrieve a frozen version of a resource will always retrieve exactly the same content, or return an error if that version (or the resource itself) are no longer available. Since URLs may be reassigned at a server's discretion this requirement applies only for that period of time during which a URL identifies the same resource. HTTP 1.1's Entity tags will need to be integrated into the versioning strategy in order for caching to work properly. ***Judy - Does the specification support this? 4.9.1.2. Policy-free Versioning. Haake and Hicks [5] have identified the notion of versioning styles (referred to here as versioning policies, to reflect the nature of client/server interaction) as one way to think about the different policies that versioning systems implement. Versioning policies include decisions on the shape of version histories (linear or branched), the granularity of change tracking, locking requirements made by a server, etc. The protocol should not unnecessarily restrict version management policies to any one paradigm. For instance, locking and version number assignment should be inter-operable across servers and clients, even if there are some differences in their preferred models. 4.9.1.3. Separation of resource retrieval and concurrency control. The protocol must separate the reservation and release of versioned resources from their access methods. Provided that consistency constraints are met before, during and after the modification of a versioned resource, no single policy for accessing a resource should be enforced by the protocol. For instance, a user may declare an intention to write before or after retrieving a resource via GET, may PUT a resource without releasing the lock, and might even request a lock via HTTP, but then retrieve the document using another communication channel such as FTP. ***Judy - The specification assumes that it's the server, not the user, that determines the policy -- order of operations and what operations are required. ***Judy - "Separation of resource retrieval and concurrency control" is supported by the Request-Lock, Request-Intent, and Request-Working-Loc parameters to the CheckOut method and the discovery mechanism. This is all embroiled in the controversy over how much latitude we want to give servers, how simple we want to make things for clients, whether we want to rely on the discovery mechanism, etc. 4.9.2. Functional Requirements ***Judy - In the specification, but not mentioned here: Diff/Merge, ServerMerge, UnVersion. 4.9.2.1. Access to specific versions via a URL. For each version of a resource, on a server, there should be a URL to refer to that version. That is, a version is itself a resource. This is required for version-specific linking, and for non-versioning client support. 4.9.2.2. A URL to denote a versioned resource itself, rather than specific versions of it. This identifier is needed for queries about the versioning status of a resource, that do not apply only to one version of that resource. It is also used to perform operations (such as adjusting attributes, changing locks, or reassigning URLs) that affect all versions of a resource, rather than any specific version. 4.9.2.3. Direct access to a server-defined "default", "current" or "tip" version of a resource. This is one of the simplest ways to guarantee non-versioning client compatibility. If no special version information is provided, the server will provide a default. This does not rule out the possibility of a server returning an error when no sensible default exists, but it does provide a standard way to support non-versioning clients, and one of the most common version access disciplines. 4.9.2.4. A way to access common related URLs from the URL of a particular version or of a versioned resource: o root version(s) of this document o predecessor version(s) of this document o successor version(s) of this document o default version of this document It must be possible in some way for a versioning client to access versions related to a resource whose URL it has. In particular, access to the "default" version of a resource is an extremely important operation, that a client should be able to perform at any time that a URL for a particular version or for a versioned resource is seen. ***Judy - Specification provides some, but not all, of these navigation paths. 4.9.2.5. A way to retrieve the complete version topology for a resource. There should be a way to retrieve information about all versions of a resource. The format for this information must be standardized so that the basic information can be used by all clients. Other specialized formats should be accomodated, for servers and clients that require information that cannot be included in the standard topology. 4.9.2.6. A way to determine whether a given URL points to a version of a versioned resource. ***Judy - Are we requiring that you be able to tell this just by examining the URL? 4.9.2.7. A way to distinguish, given a URL of a version, the part of the URL that identifies the version from the part that identifies the versioned resource. ***Judy - Do we really have to (want to) require that you be able to find out the URL of the versioned resource by examining the URL of the version? Is the requirement really just that there be some way to find out, for any version, the URL of its versioned resource? ***Judy - Specification does not provide a way to find out the URL of the versioned resource(s) to which a version belongs. Being able to determine the URL of the versioned resource makes it possible to implement browsing the version tree. It also supports some comparison operations: It makes it possible to determine whether two URLs designate versions of the same versioned resource. However, given the phenomenon of URL aliasing, it is insufficient to determine that they are not versions of the same resource. ***Judy - If 4.9.2.8 - 14 are intended to require separate operations for each of these functions, they conflict with the approach taken in the WEBDAV specification. 4.9.2.8. A way to request exclusive access to a version of a resource (Lock). (See Section 4.3 "Locking" above.) Since not all systems implement lock-based access, the protocol should not require clients to take out a lock before editing, nor should it require servers to support locking. 4.9.2.9. A way to release exclusive access to a resource (Unlock). This is the inverse of Lock. 4.9.2.10. A way for a client to declare an intention to modify a resource (Reserve). (See Section 4.4 "Notification of Intent to Edit" above.) This operation is required before any versioned update. Its effects may vary depending on server policy, from locking a resource, to forking a new variant, to a NOOP on servers that do not track sessions or restrict updates. If this operation returns a version number, the client is required to make sure that it uses a copy of the data associated with that version number of the resource for any update operations it carries out. Servers that wish to enforce a mandatory GET operation before update, should simply use a fresh version identifier on the return from this operation. 4.9.2.11. A way to declare the end of an intention to write a resource (Release). This is the inverse of Reserve. Typically, servers will commit updates at this time, and return a final version identifier if possible and if it was not already returned. 4.9.2.12. A way to submit a new version of a resource (PUT). The server should be able to attach it to the correct part of the version tree, based on the version number associated with the resource before its modification. 4.9.2.13. A way for a client to request a version identifier for a checked out version. Such an identifier will not be used by any other client in the meantime. The server may refuse the request. 4.9.2.14. A way for a client to propose a version identifier upon submitting a version of a resource. The server may refuse to to use the client's suggested version identifier. 4.9.2.15. A way for a client to supply metadata to be associated with a version. (See Section 4.1 "Attributes" above.) The kinds of data supplied here might be simple textual comments or more structured data. An ability to attach arbitrary fields and content is probably required, but a standard set of attributes that would enable interoperation would be useful. At a minimum, it must be possible to associate comments with a version, explaining what changes were made, when it is checked in. 4.9.2.16. A way for a server to provide a version identifier to be used for a resource in further operations. This identifier must accompany client requests to manipulate the resource. In particular, if a resource is being modified, the identifier must be used when submitting an update. This allows servers to track active sessions by assigning version identifiers when documents are retrieved, locked, or reserved. 4.9.2.17. A way to track resources that have been Reserved (Session Tracking). This allows the server to ensure that the user operating on a resource is the same one who Reserved it. ***Judy -- Not in the specification. ***Judy - Uncheckout is neither in the requirements nor in the specification. Do we need it? 4.9.3. Rationale Versioning in the context of the world-wide web offers a variety of benefits: It provides infrastructure for efficient and controlled management of large evolving web sites. Modern configuration management systems are built on some form of repository that can track the revision history of individual resources, and provide the higher-level tools to manage those saved versions. Basic versioning capabilities are required to support such systems. It allows parallel development and update of single resources. Since versioning systems register change by creating new objects, they enable simultaneous write access by allowing the creation of variant versions. Many also provide merge support to ease the reverse operation. It provides a framework for access control over resources. While specifics vary, most systems provide some method of controlling or tracking access to enable collaborative resource development. It allows browsing through past and alternative versions of a resource. Frequently the modification and authorship history of a resource is critical information in itself. It provides stable names that can support externally stored links for annotation and link-server support. Both annotation and link servers frequently need to store stable references to portions of resources that are not under their direct control. By providing stable states of resources, version control systems allow not only stable pointers into those resources, but also well-defined methods to determine the relationships of those states of a resource. It allows explicit semantic representation of single resources with multiple states. A versioning system directly represents the fact that a resource has an explicit history, and a persistent identity across the various states it has had during the course of that history. 5. Acknowledgements (Get current mailing list) Our understanding of these issues has emerged as the result of much thoughtful discussion, email, and assistance by many people, who deserve recognition for their effort. Martin Cagan, Continuus Software, Marty_Cagan@continuus.com Dan Connolly, World Wide Web Consortium, connolly@w3.org Ron Fein, Microsoft, ronfe@microsoft.com David Fiander, Mortice Kern Systems, davidf@mks.com Roy Fielding, U.C. Irvine, fielding@ics.uci.edu Yaron Goland, Microsoft, yarong@microsoft.com Phill Hallam-Baker, MIT, hallam@ai.mit.edu Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com Andre van der Hoek, University of Colorado, Boulder, andre@bigtime.cs.colorado.edu Gail Kaiser, Columbia University, kaiser@cs.columbia.edu Rohit Khare, World Wide Web Consortium, khare@w3.org Dave Long, America Online, dave@sb.aol.com Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com Larry Masinter, Xerox PARC, masinter@parc.xerox.com Murray Maloney, SoftQuad, murray@sq.com Jim Miller, World Wide Web Consortium, jmiller@w3.org Andrew Schulert, Microsoft, andyschu@microsoft.com Christopher Seiwald, Perforce Software, seiwald@perforce.com Richard Taylor, U.C. Irvine, taylor@ics.uci.edu Robert Thau, MIT, rst@ai.mit.edu 6. References [1] America Online, "AOL Web Tools -- AOLpress 1.2 Features." WWW page. http://www.aolpress.com/press/1.2features.html. [2] T. Berners-Lee, D. Connolly. "HyperText Markup Language Specification - 2.0." RFC 1866, MIT/LCS, November 1995. [3] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. [4] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068, U.C. Irvine, DEC, MIT/LCS, January 1997. [5] A. Haake, D. Hicks. "VerSE: Towards Hypertext Versioning Styles", Proc. Hypertext'96, the Seventh ACM Conference on Hypertext, 1996, pages 224-234. [6] Microsoft. "Microsoft FrontPage for Windows Data Sheet." WWW page. http://www.microsoft.com/msoffice/frontpage/productinfo/brochure/ default.htm. [7] K. Osterbye. "Structural and Congitive Problems in Providing Version Control for Hypertext", Proceedings of the ACM Conference on Hypertext, Milano, Italy, 1992, pp 33-42. [8] "Version Control in Hypermedia Databases" Technical report TAMU-HRL-91-004, Hypertext Research Lab, Texas A&M University. 1991. Authors' Addresses Judith Slein Xerox Corporation 800 Phillips Road 128-29E Webster, NY 14580 EMail: slein@wrc.xerox.com E. James Whitehead, Jr. Department of Information and Computer Science University of California Irvine, CA 92697-3425 Fax: 714-824-4056 EMail: ejw@ics.uci.edu David G. Durand Department of Computer Science Boston University Boston, MA EMail: dgd@cs.bu.edu Fabio Vitali Department of Computer Science University of Bologna ITALY EMail: fabio@cs.unibo.it ------------------------------- Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Internal Phone: 8*222-5169 External Phone: (716) 422-5169 Fax: (716) 265-7133 MailStop: 128-29E
Received on Monday, 10 February 1997 14:20:32 UTC