Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST

From: Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Date: Wed, Jun 07 2000

  • Next message: Clemm, Geoff: "Versioning TeleConf Agenda, 6/12/00 (Monday) 2pm-3pm EST"

    Date: Wed, 7 Jun 2000 22:59:59 -0400 (EDT)
    Message-Id: <200006080259.WAA06382@tantalum.atria.com>
    From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
    To: ietf-dav-versioning@w3.org
    Subject: Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST
    
    
    
       From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
    
       Minutes: 
       ...
          - Should checkout/checkin in a workspace be modeled as 
    	a state change of a versioned resource, or as the 
    	replacement of a versioned resource with a working resource 
    	followed by the replacement of a working resource with 
    	a versioned resource. 
    
    Note: Other than myself, the attendees of the conference call were
    unanimous in their opposition to this proposed change (i.e. they
    wanted checkout to create a working resource, and checkin to create a
    new revision and delete the working resource, and not have
    checkout/checkin be just a state change of the versioned resource).
    
    Rather than pursue this change, I've decided to take the path of
    less resistance, and withdraw my proposal that we change the protocol
    in this fashion.  This allows us to basically leave core versioning
    alone (beyond the fixes identified in the Seattle minutes), and 
    focus on finishing up advanced versioning.
    
    There is one (minor) terminological anomaly that I think it is
    important that we fix in core versioning.  Currently, we have four
    kinds of URL's:
    
    - versioned resource URL (has default target that is a revision)
    - working resource URL (mutable result of checking out a versioned resource)
    - revision URL (immutable result of checking in a working resource)
    - history URL (provides access to versioned resource metadata)
    
    Currently, if you do a PROPFIND on a versioned resource URL, the
    DAV:resourcetype is *never* DAV:versioned-resource, while if you do a
    PROPFIND on a history URL, the DAV:resourcetype is *always*
    DAV:versioned-resource.
    
    I propose that we change the name of this resource type to be
    DAV:history.  Then if you do a PROPFIND on a history URL, the
    DAV:resourcetype will be DAV:history.  This makes it clear that
    this resource is displaying the history of the versioned resource,
    and not the default target of the versioned resource.
    
    Note that this involves *no* change to the protocol, beyond
    renaming this one string.
    
    Although not a big deal for core versioning, this is very important
    for preventing confusion in advanced versioning, where you can either
    have two bindings in the same workspace to the same versioned resource
    (all of which then have the same default target), or you can have
    two versioned resources in different workspaces with different default
    targets, but which are associated with the same "history" resource.
    
    Cheers,
    Geoff