Link Relations for Simple Version Navigation

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.¶

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 documents as Internet-Drafts.¶

Internet-Drafts are draft documents valid for a maximum of six months and may 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 other than as “work in progress”.¶

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.¶

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.¶

This Internet-Draft will expire on December 14, 2009.¶

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

This specification defines Atom link relations for navigation between a resource and its versions.¶

This specification defines link relations that may be used on a resource that exists in a system that supports versioning to navigate among the different resources available, such as past versions.¶

The terms below are borrowed from the Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) ([RFC3253]).¶

Version-Controlled Resource, Checked-Out ¶

• When a versionable resource is put under version control, it becomes a "version-controlled resource". A version-controlled resource can be "checked out" to allow modification.

Checked-Out Resource ¶

• A "checked-out resource" is a resource under version control that is in the checked-out state.

Version Resource ¶

• A "version resource", or simply "version", is a resource that contains a copy of a particular state of a version-controlled resource. A version is created by "checking in" a checked-out resource. The server allocates a distinct new URL for each new version.

Version History Resource ¶

• A "version history resource", or simply "version history", is a resource that contains all the versions of a particular version-controlled resource.

Predecessor, Successor, Ancestor, Descendant ¶

• When a version-controlled resource is checked out and then subsequently checked in, the version that was checked out becomes a "predecessor" of the version created by the checkin. A client can specify multiple predecessors for a new version if the new version is logically a merge of those predecessors. When a version is connected to another version by traversing one or more predecessor relations, it is called an "ancestor" of that version. The inverse of the predecessor and ancestor relations are the "successor" and "descendant" relations. Therefore, if X is a predecessor of Y, then Y is a successor of X, and if X is an ancestor of Y, then Y is a descendant of X.

Root Version Resource ¶

• The "root version resource", or simply "root version", is the version in a version history that is an ancestor of every other version in that version history.

Working Resource ¶

• A "working resource" is a checked-out resource created by the server at a server-defined URL when a version (instead of a version-controlled resource) is checked out. [issue.working.resource: Is this true for JCR and CMIS as well? Maybe we need to relax the definition? --jre]

all-versions

When included on a version controlled resource, this link points to a resource containing the version history for this resource.

latest-version

When included on a version controlled resource, this link points to a resource containing the latest (e.g., current) version. [issue.latest.version: I think "latest" is misleading, as it may not be the "latest" when different branches are involved. JCR 1.0 has "base version", defined as "The base version of a particular node N is the one that will serve as the default immediate predecessor of the next version of N that is created." -- can we adopt that? (see <http://www.day.com/specs/jcr/1.0/8.2.3_The_Base_Version.html>). --jre]

working-copy

When included on a Checked-Out resource, this link points to a Working Resource. [issue.working.resource.2: I think the working resource *is* checked out, and the link lives on either a version or version controlled resource (which stays checked in). --jre]

predecessor-version

When included on a version resource, this link points to a resource containing the predecessor version in the version history.

successor-version

When included on a version resource, this link points to a resource containing the successor version in the version history.

[rfc.comment.1: To Be Done] ¶

Automated agents should take care when these relation crosses administrative domains (e.g., the URI has a different authority than the current document).¶

The link relations defined in Section 3 are to be registered by IANA per [RFC4287].¶

All link relations defined in this document will have the following expected display characteristics: ¶

• Undefined; this relation can be used for background processing or to provide extended functionality without displaying its value.

[rfc.comment.2: To Be Done: describe how versioning properties in JCR and in WebDAV/DeltaV map to the newly defined link relations.] ¶

The content and concepts within are a product of the Content Management Interoperability Services (CMIS) Technical Committee (TC) at OASIS.¶

All members of the TC have contributed.¶