- From: Jan Algermissen <algermissen1971@mac.com>
- Date: Mon, 30 Nov 2009 17:28:12 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, Atom-syntax Syntax' <atom-syntax@imc.org>, WebDAV <w3c-dist-auth@w3.org>, w3c-dist-auth-request@w3.org
On Nov 30, 2009, at 5:06 PM, Julian Reschke wrote: > Jan Algermissen wrote: >>> Does it? >>> >>> "A "working copy" is a resource at a server-defined URL that can >>> be modified to create a new version of a versioned resource." >>> >> So it might be enough to: >> PUT /working-copies/667 >> <foo/> >> to create a new version of /main/667 ?? (assuming that /main/667 -- >> working-copy--> /working-copies/667) >> What would be the reason to have a working copy that needs not be >> checked-in? > > That's not what I intended to say; I was just pointing out that the > current definition in the spec does not refer to checkin/checkout > (maybe it should?). 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." 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. Jan > > BR, Julian -------------------------------------- Jan Algermissen Mail: algermissen@acm.org Blog: http://algermissen.blogspot.com/ Home: http://www.jalgermissen.com --------------------------------------
Received on Monday, 30 November 2009 16:29:01 UTC