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>