Re: Comments on Action:draft-brown-versioning-link-relations-03

Jan Algermissen wrote:
> Julian,
> 
> On Dec 1, 2009, at 3:07 PM, Julian Reschke wrote:
> 
>> Jan Algermissen wrote:
>>> ...
>>> Hmm, I think so. The definition in a sense implies that the version 
>>> is created as a result of the modification. Which is IMHO *never* the 
>>> case for working copies.
>>> Surely the draft must define 'working copy'. What is the nature of a 
>>> working copy? What is its true nature? I think: being *used* for 
>>> creating new versions. So, what about:
>>>>>> "A "working copy" is a resource at a server-defined URL that can 
>>>>>> be *used* to create a new version of a versioned resource."
>>> ...
>>
>> So, substituting "modified" by "used". I'm ok with that.
> 
> Fine.
> 
>>
>>> and remove checkout/checkin completely. ('use' instead of 'modify' 
>>> sounds less like "The modification cause the versioning" (which it 
>>> never does by nature of a working copy (IMHO - s.a.))
>>> If the draft wanted to define it, then it woud be something like:
>>> checkout: an operation on a resource that creates a working copy
>>> checkin: an operation on a working copy that creates a new version of 
>>> its corresponding versioned resource.
>>
>> The issue here is that in some systems, checkout will not create a new 
>> resource, just flip a bit on the versioned resource.
>>
>> Also, (I think) there are systems where checking in does not create a 
>> new version, but flips a bit on the working resource *making* it a 
>> version (at the same URL).
>>
>> Thus, defining this would need to be defined in a more generic way. My 
>> attempt:
>>
>> "Checkout: an operation on a versioned resource that creates a working 
>> copy, or changes the versioned resource to be a working-copy as well 
>> ("in-place versioning").
>>
>> Checkin: an operation on a working copy that creates a new version of
>> its corresponding versioned resource.
>>
>> Note: the operations for putting a resource under version control, and 
>> for checking in and checking out depend on the protocol in use and are 
>> beyond the scope of this document; see [CMIS], [RFC3253] and [JSR-283] 
>> for details)."
> 
> 
> Sounds good to me.
> ...

OK, I have added the text as proposed in my copy at 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html>, 
the terminology section now reads:

    Versioned Resource

       When a resource is put under version control, it becomes a
       "versioned resource".  Many servers protect versioned resources
       from modifications by considering them "checked in", and by
       requiring a "checkout" operation before modification, and a
       "checkin" operation to get back to the "checked-in" state.  Other
       servers allow modification, in which case the checkout/checkin
       operation may happen implicitly.

    Version History

       A "version history" resource is a resource that contains all the
       versions of a particular versioned resource.

    Predecessor, Successor

       When a versioned 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.  The inverse of the
       predecessor relation is the "successor" relation.  Therefore, if X
       is a predecessor of Y, then Y is a successor of X.

    Working Copy

       A "working copy" is a resource at a server-defined URL that can be
       used to create a new version of a versioned resource.

    Checkin

       A "checkin" is an operation on a versioned resource that creates a
       working copy, or changes the versioned resource to be a working-
       copy as well ("in-place versioning").

    Checkout

       A "checkout" is an operation on a working copy that creates a new
       version of its corresponding versioned resource.

       Note: the operations for putting a resource under version control,
       and for checking in and checking out depend on the protocol in use
       and are beyond the scope of this document; see [CMIS], [RFC3253]
       and [JSR-283] for examples.

...as always, feedback appreciated,

Julian

Received on Wednesday, 2 December 2009 17:59:50 UTC