One document matched: draft-brown-versioning-link-relations-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-brown-versioning-link-relations-01" category="info">
	<front>
		<title abbrev="Version Navigation Link Relations">Link Relations for Simple Version Navigation</title>

		<author initials="A. B." surname="Brown" fullname="Al Brown">
			<organization>IBM</organization>
			<address>
				<postal>
					<street>3565 Harbor Blvd</street>
					<city>Costa Mesa</city>
					<region>California</region>
					<code>92626</code>
					<country>US</country>
				</postal>
				<email>albertcbrown@us.ibm.com</email>
				<!--<uri></uri>-->
			</address>
		</author>

    <author initials="G." surname="Clemm" fullname="Geoffrey Clemm">
      <organization>IBM</organization>
      <address>
        <postal>
          <street>20 Maguire Road</street>
          <city>Lexington</city>
          <region>MA</region>
          <code>02421</code>
					<country>US</country>
        </postal>
        <email>geoffrey.clemm@us.ibm.com</email>
      </address>
    </author>
    
		<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
			<organization abbrev="greenbytes">greenbytes GmbH</organization>
			<address>
				<postal>
					<street>Hafenweg 16</street>
					<city>Muenster</city>
					<region>NW</region>
					<code>48155</code>
					<country>Germany</country>
				</postal>
				<email>julian.reschke@greenbytes.de</email>
				<uri>http://greenbytes.de/tech/webdav/</uri>
			</address>
		</author>

		<date day="13" month="July" year="2009"/>

		<abstract>
			<t>
        This specification defines Atom link relations for navigation between
        a resource and its versions.
			</t>
		</abstract>

    <note title="Editorial Note (To be removed by RFC Editor before publication)">
      <t>
        Please send comments to the Atom Syntax mailing list
        (<eref target="http://www.imc.org/atom-syntax/"/>).
      </t>
    </note>

	</front>

	<middle>

		<section title="Introduction" anchor="introduction">
			<t>
				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.
      </t>
		</section>

		<section title="Terminology" anchor="terminology">
      <t>
        The terms below are borrowed from the Versioning Extensions to WebDAV
        (Web Distributed Authoring and Versioning) (<xref target="RFC3253"/>).
      </t>
			<t>
				<?rfc needLines="4"?>Version-Controlled Resource, Checked-Out
				<list>
					<t>
						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.
          </t>
				</list>
			</t>
			<t>
				<?rfc needLines="4"?>Checked-Out Resource
				<list>
					<t>
						A "checked-out resource" is a resource under version control that
						is in the checked-out state.
          </t>
				</list>
			</t>
			<t>
				<?rfc needLines="4"?>Version Resource
				<list>
					<t>
						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.
          </t>
				</list>
			</t>
			<t>
				<?rfc needLines="4"?>Version History Resource
				<list>
					<t>
						A "version history resource", or simply "version
						history", is a resource that contains all the versions of a
						particular version-controlled resource.
          </t>
				</list>
			</t>
			<t>
				<?rfc needLines="4"?>Predecessor, Successor, Ancestor, Descendant
				<list>
					<t>
            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.
          </t>
				</list>
			</t>
			<t>
				<?rfc needLines="4"?>Root Version Resource
				<list>
					<t>
						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.
          </t>
				</list>
			</t>
			<t>
				<?rfc needLines="4"?>Working Resource
				<list>
					<t>
						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. <!--Unlike a checked-out
						version-controlled resource, a working
						resource is deleted when it
						is checked in.-->
            <cref source="jre" anchor="issue.working.resource">
              Is this true for JCR and CMIS as well? Maybe we need to relax
              the definition?
            </cref>
          </t>
				</list>
			</t>
		</section>

		<section title="Link Relations" anchor="linkrelations">
			<t>
				The following link relations are defined:
      </t>
			<t>
				<list style="hanging">
					<t hangText="version-history">
						When included on a version controlled resource, this
						link points to a resource containing the version history for this
						resource.
          </t>
					<t hangText="latest-version">
						When included on a version controlled resource, this
						link points to a resource containing the latest (e.g., current)
						version.
            <cref source="jre" anchor="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>).
            </cref>
          </t>
					<t hangText="working-copy">
						When included on a version resource, this link
						points to a Working Resource.
          </t>
					<t hangText="predecessor-version">
						When included on a version resource, this
						link points to a resource containing the predecessor version in the
						version history.
          </t>
					<t hangText="successor-version">
						When included on a version resource, this
						link points to a resource containing the successor version in the
						version history.
					</t>
				</list>
			</t>
		</section>

    <section title="Examples">
      <t>
        <cref>To Be Done</cref>
      </t>
    </section>
    
		<section title="Security Considerations" anchor="security">
			<t>
				Automated agents should take care when these relation
				crosses administrative domains (e.g., the URI has a different
				authority than the current document).
			</t>
		</section>

		<section title="IANA Considerations" anchor="iana">
			<t>
				The link relations defined in <xref target="linkrelations"/>
        are to be registered by IANA per
				<xref target="RFC4287"/>.
			</t>
			<t>
				All link relations defined in this document will have the following
				expected display characteristics:
        <list>
          <t>
    				Undefined; this relation can be used for background processing or to provide
    				extended functionality without displaying its value.
          </t>
        </list>
			</t>
		</section>


	</middle>
	<back>
		<references title="Normative References">

      <reference anchor="RFC4287">
        <front>
          <title>The Atom Syndication Format</title>
          <author fullname="M. Nottingham" surname="Nottingham" initials="M.">
            <organization/>
          </author>
          <author fullname="R. Sayre" surname="Sayre" initials="R.">
            <organization/>
          </author>
          <date month="December" year="2005"/>
        </front>
        <seriesInfo name="RFC" value="4287"/>
      </reference>

		</references>

		<references title="Informative References">

			<reference anchor="RFC3253">
				<front>
					<title>Versioning Extensions to WebDAV (Web Distributed
						Authoring and Versioning)</title>
					<author fullname="G. Clemm" surname="Clemm" initials="G.">
						<organization>Rational Software (IBM)</organization>
					</author>
					<author fullname="J. Amsden" surname="Amsden" initials="J.">
						<organization/>
					</author>
					<author fullname="T. Ellison" surname="Ellison" initials="T.">
						<organization>IBM</organization>
					</author>
					<author fullname="C. Kaler" surname="Kaler" initials="C.">
						<organization>Microsoft</organization>
					</author>
					<author fullname="J. Whitehead" surname="Whitehead" initials="J.">
						<organization>U.C. Santa Cruz</organization>
					</author>
					<date month="March" year="2002"/>
				</front>
				<seriesInfo name="RFC" value="3253"/>
			</reference>

		</references>

    <section title="Relationship to JCR and WebDAV">
      <t>
        <cref>To Be Done: describe how versioning properties in JCR
        and in WebDAV/DeltaV map to the newly defined link relations.</cref>
      </t>
    </section>
    
		<section title="Contributors" anchor="contributors">
			<t>
				The content and concepts within are a product of the Content Management
				Interoperability Services (CMIS) Technical Committee (TC) at OASIS.
			</t>
      <t>
				All members of the TC have contributed.
			</t>
		</section>

		<section title="Change Log (to be removed by RFC Editor before publication)" anchor="changes">

    <section title="Since draft-brown-link-relations-00">
      <t>
        Added Geoff Clemm as author.
      </t>
      <t>
        Renamed link relation "all-versions" to "version-history". Fixed
        description of "working-resource" relation to state that it appears
        on a version resource.
      </t>
    </section>

		</section>

	</back>

</rfc>