- From: Jan Algermissen <algermissen1971@mac.com>
- Date: Thu, 26 Nov 2009 17:08:14 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Atom-syntax Syntax' <atom-syntax@imc.org>, WebDAV <w3c-dist-auth@w3.org>
On Nov 26, 2009, at 4:51 PM, Julian Reschke wrote: > Jan Algermissen wrote: >> Do you have a (rough) set of use cases (IOW: client goals) that are >> to be enabled by the link relations? >> Along the lines: "Client needs to find a working-copy" => link rel >> working-copy enables that > > These use cases mainly come from CMIS (content management over > AtomPub); and the main reason these aren't mentioned in the spec is > that we wanted to avoid a circular spec reference. > > See <http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html > >. > >> ... > > An alternative would be not to use the terminology around checkin/ > checkout at all. I'll give that a try. Reading your reference, I think that the important semantic is that updating a working-copy does not produce a version, IOW, that, in order to create a new version from a working-draft the draft must be checked in. Hence, the notion of check-in is definitely necessary. The actual operation is othogonal (could be a CHECK-IN method or a standard HTTP 1.1 request to a resource that has the appropriate semantics) but the general notion is fundamental to the idea of a working-copy. check-out I think could be dropped because when I know that something is a working-copy it is by definition checked out. ... well then, the notion of check-in implies the notion of check-out, so both are a vital part in the end. Jan > > Best regards, Julian -------------------------------------- Jan Algermissen Mail: algermissen@acm.org Blog: http://algermissen.blogspot.com/ Home: http://www.jalgermissen.com --------------------------------------
Received on Thursday, 26 November 2009 16:08:53 UTC