[Prev][Next][Index][Thread]

Reading version of draft Functional requirements for basic versioning



Well, in the constant triage of life, the revised text is going to the
group now. The IETF submission will have to wait until Fridaym or after the
meeting. Feel free to critique again. It's not even proofed yet, so
detection of howlers is great even if you agree w/ everything said within.

The follwoing is also available at:
http://www.cs.bu.edu/students/grads/dgd/draft-versioning-req-00.html

The HTML is somewhat cleaned up for non-Netscape browsers.

   -- David


<HTML>
<HEAD>
<TITLE>Functional Requirements and Framework for Versioning on the WWW</TITLE>
</HEAD>
<BODY>

<H1>Functional Requirements and Framework for Versioning on the WWW</H1>
<h2>David G. Durand and Fabio Vitali</h2>

<h2>Changes from last version</h2>

<UL>
<LI>lock durations</LI>
<LI>separate locking / resource reservation</LI>
<LI>clarify/reorder points</LI>
<LI>style-free versioning</LI>
<LI></LI>
</UL>

<h2>Abstract</h2>

<P>
This document describes the functional requirements for integrating
versioning into the WWW.  Versioning is the fundamental basis of document
management systems, with far reaching effects on the semantics of document
identity and meaningful operations.  These requirements reflect
the basic versioning needs for document management and collaborative
authoring.  It does not define the complete set of requirements for these
domains where they extend beyond the versioning of resources.
</P>

<h2>1. Introduction</h2>
<P>This document discusses why versioning is needed on the WWW, and the
functional requirements for full version support.  We have divided the
requirements in three sections.  This discussion enumerates the reqirements
for implementing such functionality as a first step to creating a
specification that will address these needs.

<p>We first briefly describe the rationale for versioning on the web in
Section 2.  This rationale enumerates the goals of versioning on the WWW.
All specific requirements should support (and certainly should not hinder)
the realization of the goals.  Section 3 contains global requirements for
protocol development.  These are things we think are technically justified
and that fulfil the rationale.  They are separated from the other
requirements because their acceptance creates further constraints on other
technical requirements.  Finally, In Section 4, we specific functional
requirements based on the foundation established in the earlier sections.

<p>We have based this effort on David Fiander's suggestion to separate
versioning and configuration requirements, and we assume a two-layer
architecture for versioning on the web.  The first layer, whose
requirements are defined in this document, will address the simple problem
of <EM>handling multiple versions of single resources.</EM> The second
layer will address the thornier problems of configuration management for
multiple resources.  This layering simplifies both discussion and design.

<H2>2. Rationale</H2>

<P>Versioning in the context of the world-wide web offers a variety of
benefits:</P>

<ol>
<LI>It provides infrastructure for efficient and controlled
management of large evolving web sites.
<br><br>Modern configuration management systems are built on some form of
repository that can track the revision history of individual resources, and
provide the higher-levelools to manage those saved versions. Basic
versioning capabilities are required to support such systems.</li>
<LI>It allows parallel development and update of single resources
<br><br>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 revers operation.</LI>

<LI>It provides a framework for access control over resources.
<br><br>While specifics vary, most systems provide some method of
controlling or
tracking access to enable collaborative resource development.</LI>

<LI>It allows browsing through past and alternative versions of a
resource
<br><br>Frequently the modification and authorship history of a resource is
critical information in itself.</LI>

<LI>It provides stable names that can support externally stored links for
annotation and link-server support.
<br><br>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.</LI>

<LI>It allows explicit semantic representation of single resources with
multiple states
<br><br>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.</LI>
</ol>

<H2>3. Global requirements</H2>

<P>This section covers the overarching contraints that must
inform and direct detailed requirements for versioning support.  They
encompass compatibility across different implementations, as well as
compatibility with current practice.  Therefore, we believe the following
to be the general requirements for WWW versioning:
</P>

<ol>
<LI><EM>Stableness of versions.</EM>
<br>
Most versioning systems are intended to enable 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.
</li>
<br>
<LI><EM>User Agent Interoperability.</EM>
<br>
All versioning-aware user agents should be able to work with any
versioning-aware HTTP server.  It is acceptable for some user agent/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.
</li>
<li><em>Style-free Versioning</em>
<br>
The protocol should not unnecessarily restrict version management style to
any one paradigm.  For instance, locking and version number assignment
should be interoperable across servers and clients, even if there are some
differences in their preferred models.

<LI><em>Separation of access to resources and access control</em>
<br>
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 "right way" to access to a resource is enforced by the protocol.  For
instance, a user may request declare an intention to write after a GET, may
POST a resource without releasing the lock, and might even request a lock
via HTTP connection while getting the document via FTP.</LI>

<LI><EM>Legacy Resource Support.</EM>
<br>
The protocol should enable a versioning aware server to work with existing
resources and URLs.  Special versioning information should not become a
mandatory part of HTTP protocols except where it is required.  Special
version information that would break existing clients and servers, such as new
mandatory headers, cannot therefore be required for GET (and possibly also for
PUT).
</LI>

<LI><EM>Legacy User Agent Support.</EM>
<br>
Servers should make versioned resources accessible to versioning-unaware
user-agents in a format acceptable to them.
</LI>

<li><EM>Specific named version URLs that are constructed from a URL
and an opaque version string</EM>
<br>
Because the notation will be required to operate in the version control
environment preferred by the website maintainer, it must be able to
properly contain arbitrary strings, which may be used by the VCS as version
identifiers.  While version information may be intelligible to the human
operator, and perhaps to special-purpose clients, the client must be
able to treat the version specifier as a black box.
</li>
</ol>

<H2>4. Functional requirements</H2>
<p>The following functional reqirements are intended to satisfy the global
requirements of Section 3 and enable the benefits listed in Section 2.  The
mention of possible new HTTP methods is intended to make the discussion
clearer and more concrete, not to rule out other methods of meeting the
requirements.

<P>The protocol should provide:</P>

<ol>
<LI><em>Access to specific named versions via a URL</em>
<br>
This is required for version-specific linking, and for legacy user-agent
support.</li>

<li><em>A URL to denote a versioned resource itself, rather than specific
versions of it</em>
<br>
This is more important if URL computations are not allowed, since an
identifier is needed for queries about the versioning status of a resource.
This is 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.
</li>

<LI><EM>Direct access to a server-defined "default", "current" or "tip" version
of a resource</EM>
<br>
This is one of the simplest ways to guarantee legacy user-agent
compatibility and legacy file compatibility.  If no special version URLs
are used, the server will provide a default.  This does not rule out the
possibility of a server returning an error in case no such default exists.
</LI>

<LI><em>A way to access common related URLs from a versioned URL,</em>
whether by
server query, URL computation, or some other way:
<UL>
<LI>root version(s) of this document</LI>
<LI>predecessor version(s) of this document</LI>
<LI>successor version(s) of this document</LI>
<LI>default version of this document</LI>
</UL>
Some versions of a resource are special.  It must be possible in some way
for a versioning-aware client to access common related versions to the one
it currently is displaying.  Possible solutions include, but are not
limited to: the server automatically adding header fields to a versioned
URL specifying the URL of the common related versions, the server providing
one or more query methods ("who is the previous version to this URL?"), or
a standardized way to compute related URLs when given a versioned URL. We
feel that access to the "default" version of a resource is an extremely
important operation, that a browser should be able to perform at any time
that a versioned URL is seen.
</strong></LI>

<LI><EM>A way to retrieve the complete version topology for this resource</EM>
<br>
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.  </LI>

<LI><EM>Some way to determine that a
URL points to a named version of a resource</EM>
<br>
This might be implemented as part of the URL format, a server query or
additional headers.
</li>

<li><EM>Some way to determine a version identification and a resource
identification for a versioned resource, given its URL</EM>
<br>
This requirement describe the ability to take the URL of a version of a
resource and determine:
<ul>
<li>a URL for the resource</li>
<li>a version identifier for the resource.</li>
</ul>
Note that this kind of facility supports only some comparison operations: It
enables the determination that two version-containing URLs designate
versions of the same resource.  However, given the phenomenon of URL
aliasing, it is insufficient to determine that they are <EM>not</EM>
versions of the same resource.
<br><br>
This is sort of a minimal "browsing
through time" requirement.  Tthis requirement allows a browser to tell that a
versioned resource has been accessed and then to invoke special versioning
or configuration management operations on the resource.  While client
performance will be best if this can be done via URL computation (ie.
mangling) it could also be done by an extra query and round-trip to
the server.</LI>

<LI><EM>A way to request exclusive access to a version of a resource
(LOCK)</EM>
<br>
Since not all systems implement lock-based access there is a
question as how this should be implemented. Client use of this
method could be optional, allowing some relatively strong guarantee on the
meaning of acquiring a lock.  Alternatively, clients could be expected to
take a lock, but servers might implement different locking policies
(possible even including implementation of LOCK and UNLOCK as NOPS).
</LI>

<li><EM>A way to specify a timeout after which a lock will lapse</EM>
<br>
In many cases, locks over a certain duration are due to errors, and their
strict enforcement can cause more problems than inadvertent version skew.
We should allow locks to have a lifetime.  It <EM>may</EM> prove a good idea to
have a finite default lifetime defined by the protocol.  If a universal
default is too constraining, there should be a way for a server to inform
the client what the lifetime of a lock is.  Servers should honor client
lock lifetime requests, or inform them if the request is denied.

<LI><EM>A way to release exclusive acccess to a resource (UNLOCK)</EM>
<br>
This is the inverse of LOCK.</LI>

<li><em>A way for a client to declare an intention to modify a resource
(RESERVE or CHECKOUT?)</em>
<br>
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 NOP 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.
</li>

<li><em>A way to declare the end of an intention to write a resource</em>
<br>
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.</li>

<LI><EM>A way to submit a new version of a resource (PUT)</EM>
<br>
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.
</li>

<LI><em>A way for a user-agent to request a version identifier for a checked
out version.</em>
<br>
Such an identifier will not be used by any other
user-agent in the meantime.  The server may refuse the request.</LI>

<li><EM>A way for a client to propose a version identifier upon
submitting a version of a resource</EM>
<br>
The server may refuse to to use the client's suggested version identifier.
</LI>

<li><em>A way for a Client to supply metatdata to be associated with a
version</em>
<br>
The kinds of data supplied here might be simple textual comments or more
structured data.  An ability to attach aritrary fields and content is
probably required, but a standard set of attributes that would enable
interoperation would be useful.  For basic versioning we need only specify,
for example, that comments are attached as the message-body of the operation
that releases a write intention.  The special formats for structured metadata
can then be handled by using content-type negotiation, and the
content-types defined as part of the Configuration Management layer.
</li>
<li><em>A way for a server to provide a version identifier to be used for a
resource in further operations/</em>
<br>
This general requirement notes that version aware clients are responsible
for providing the appropriate version identifier for a resource that is
being manipulated.  In particular, if a resource is being modified, any
server provided version must be used when submitting an update.  This
allows servers to track active sessions (however they may be implemented by
the server) by assigning version identifiers when documents are retrieved,
locked, or reserved.
</li>
</ol>

<p>The following discussion of possible implementations of the requirements
above is intended to aid understanding of the requirements.  It is
<em>not</em> a statement that a particular implementation is a requirement
for basic versioning, but an explanation of how the separation of concerns
might improve the final implementation architecture.

<p>The requirements on reservation and PUT take care some key global
requirements: version access is logically separated from access control
(RESERVE/RELEASE) and updating.  In terms of traditional CM, a CHECKOUT is a
RESERVE followed by a GET and a CHECKIN is a PUT followed by an RELEASE.  By
separating access control (locking and unlocking of resources) from
modification of resources, we achieve a great deal of versioning-style
independence.

<p>We also have very flexible options for the negotiation of
version identifiers depending on server policy.  The version identifier of a
new resource can be negotiated between the user-agent and the server at 3
points in time: when a lock is taken, when the lock is released, or when
the resource is POSTed.  Session tracking can be implemented by using
special version identifiers for RESERVE and RELEASE.  All version
identifier negotiation follows a simple rule: "the client proposes, but the
server disposes."

<h2>Acknowledgements</h2>
<p>This document is a result of the vigorous and valuable discussion on the
Versioning on the Web <A HREF="mailto:www-vers-wg-request@ics.uci.edu">
&lt;www-vers-wg-request@ics.uci.edu&gt;</A>, and the Distributed Authoring
<A
HREF="mailto:w3c-dist-auth-request@w3.org">&lt;w3c-dist-auth-request@w3.org&
gt;</A>
mailing lists.  All the the interactions on these lists have been helpful,
as have several conversations.
David Fiander's initial requirements got us started and clarified several
points .  Jim Whitehead provided useful criticism, some new points, and
impetus to get this thing out the door.  Yaron Golan and Christopher
Seiwald provided extensive commentary and discussion.
<p>The following list include the above and others who have also helped
either with their postings, personal email or face-to-face discussions:

<p>
Dan Connolly, World Wide Web Consortium, connolly@w3.org<br>
Ron Fein, Microsoft, ronfe@microsoft.com<br>
David Fiander, Mortice Kern Systems, davidf@mks.com<br>
Roy Fielding, U.C. Irvine, fielding@ics.uci.edu<br>
Yaron Goland, Microsoft, yarong@microsoft.com<br>
Dave Long, America Online, dave@sb.aol.com<br>
Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org<br>
Larry Masinter, Xerox PARC, masinter@parc.xerox.com<br>
Murray Maloney, SoftQuad, murray@sq.com<br>
Christopher Seiwald, Perforce Software, seiwald@perforce.com<br>
Judith Slein, Xerox, slein@wrc.xeroc.com<br>
</p>
<h2>To Do</h2>

<P>
Mandatory IETF formatting.  Proofread.  Spell check.  Sanity check.
</P>

</BODY></HTML>

--------------------------------------------+--------------------------
David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science          | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/



Follow-Ups: