Re: RE: Comments on section 4.9 of the requirements specification

Sorry for the late reply on this thread. I would like to make sure that the
concepts promoted by Document Management Systems (DMS) be supported
as well. Basically, a "version" in a DMS is just a previous version (or revision)
of the document and CAN be altered any time in the future. That is why
we make the distinction between the CHECKOUT/IN and (UN)LOCK methods
in the specification.

-src

>>> Yaron Goland <yarong@microsoft.com> 02/17/97 01:43AM >>>
Regarding 4.9.1.1 I believe that a requirements document should discuss
the concept of frozen and unfrozen versions and the need for the
protocol to distinguish between the two. It should not, however, specify
how that distinction is made.

As for uncheckout, I suspect I will eventually convince myself that you
are right so I will drop the subject. =)

  Yaron

>-----Original Message-----
>From: Fabio Vitali [SMTP:fabio@CS.UniBO.IT] 
>Sent: Friday, February 14, 1997 2:55 AM
>To: Yaron Goland
>Cc: 'w3c-dist-auth@w3.org' 
>Subject: Re: Comments on section 4.9 of the requirements specification
>
>> 4.9.1.1. Stableness of versions. Most versioning systems are intended
>>to
>> provide an accurate record of the history of evolution of a document.
>> This accuracy is ensured by the fact that a version eventually becomes
>> "frozen" and immutable. Once a version is frozen, further changes will
>> create new versions rather than modifying the original. In order for
>> caching and persistent references to be properly maintained, a client
>> must be able to determine that a version has been frozen. We require
>> that unlocked resource versions be frozen. This enables the common
>> practice of keeping unfrozen "working versions". Any successful attempt
>> to retrieve a frozen version of a resource will always retrieve exactly
>> the same content, or return an error if that version (or the resource
>> itself) are no longer available.  Since URLs may be reassigned at a
>> server's discretion this requirement applies only for that period of
>> time during which a URL identifies the same resource. HTTP 1.1's Entity
>> tags will need to be integrated into the versioning strategy in order
>> for caching to work properly.
>>
>> ***Judy - Does the specification support this?
>>
>>I'm not sure. The sentence "We require that unlocked resource versions
>>be frozen." sets off a lot of bells. I thought we were going to support
>>lock free versioning?
>
>Well, taking the risk of another flame, let me explain this sentence. If
>you think we were stepping over the work of the spec builder, say so...
>only, gentler, please. :-)
>
>In order for a multi-author system to work, it must handle consistency for
>multiple check-ins. This can either be through a strong lock, or by
>providing a different mechanism (e.g. branching version trees, and so on).
>
>So asking for an unlocked version to be frozen simply means that only
>locked versions can be substituted with a fresher copy, while unlocked
>versions either require a lock before being modified, or, for lock-free
>systems, always create a new version, and thus can never be modified
>directly.
>
>There are thousands of other (possibly better) ways to put it. In my
>proposal for section 4.9 I deleted it altogether.
>
>> ***Judy - Uncheckout is neither in the requirements nor in the
>> specification.  Do we need it?
>>
>>I would strongly argue that we do. The scenario of a user checking out a
>>document and then changing their mind and wanting to Uncheckout the
>>document is so common that just about every single versioning system in
>>existence supports it.
>
>I believe this functionality was given with a "release". I believe
>"uncheckout" is the opposite of the "intention to edit".  It should not e
>assumed to imply also an "unlock", though, since I believe it is possible
>that I change my idea about modifying a resource, but still I don't want
>the resource to be freely modifiable.
>
>Fabio
>

Received on Tuesday, 25 March 1997 11:16:24 UTC