High-level capabilities

Jim Whitehead (ejw@ics.uci.edu)
Thu, 6 Jun 1996 11:57:28 -0700 

In my opinion, a minimal set of user capabilities which would provide a
useful environment for browsing and authoring versioned entities, and
collections of entities, is listed below.  This text is a massaged form of
a section from my versioning proposal (now available in HTML format from
the working group page, <http://www.ics.uci.edu/~ejw/versioning/>).

These capabilities can be divided into two groupings:
  - capabilities which support browsing
  - capabilities which support authoring

Browsing support capabilities:

1. Retrieval of a stated version of an entity: Any given revision of an
entity should be accessible, thus supporting links to stated revisions of
entities.  (This capability is provided by the ";version={opaque version
id}" capability we have been discussing.)

2. Browsing within a collection of entities: Often multiple entities
together form a logical grouping, for example, a collection of HTML and GIF
entities which comprise online documentation for a software product.  It is
desirable to provide support for browsing within such a collection without
requiring either the user or the entities to explicitly name the
destination entity version of each link traversal.

3. Retrieval of derivation relationships between versions of an entity: The
ability to trace the development and ownership of an entity provides
visibility into the development of that entity, and into the namespace of
version identifiers for versions of that entity.

Authoring support capabilities:

4. Writing to a given version of an entity: Once changes have been made to
an entity, versioning policies often dictate that the changes be written
into a new, stated version of that entity.

5. Policy-neutral versioning: the methods defined for accessing, modifing,
and locking entities should allow multiple versioning policies to be built
on top of them.  For example, lock-based policies, as employed by RCS, and
merge-based policies, as implemented in CVS, should both be implementable.
Since a wide range of applications will use versioning, the greater the
flexibility in the types of versioning policies which may be supported, the
greater the types of applications that can employ this protocol.

6. Parallel development support: Since it frequently occurs that multiple
people edit the same entity simultaneously, this type of activity must be
supported.  User agents must be supplied with enough information to inform
their users when they are entering a parallel development situation, and
they must be supplied with the versions of parallel entities so they can
provide merge support for the entity contents.  Futhermore, since it is
currently beyond the state of the art to provide merge support for certain
entity types (e.g., MPEG video), it must be possible to disallow parallel
development on these entity types.

7. Visibility control: Through the user agent, it should be possible to
control the external visibility of an entity.  For example, this is useful
for ensuring that working revisions of an entity are not accessible by the
entire world.

8. Configuration support: The user must be able to create versioned
collections of versioned entities.  When creating online documentation, an
author will create multiple pages, which may, for example, contain an HTML
document and supporting bitmap graphics and applet objects.  The author
will want to make a versionable collection of the entities which comprise
each page, as well as a versionable collection of all the pages.

Note that you might not want all users to be able to employ all
capabilities all the time.  For the development of these requirements, I
have assumed a super-user who would be able to do everything, all the time.
Access control mechanisms can limit which users can employ which
capabilities.

- Jim Whitehead <ejw@ics.uci.edu>