W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2009

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

From: Jan Algermissen <algermissen1971@mac.com>
Date: Thu, 26 Nov 2009 17:08:14 +0100
Cc: Atom-syntax Syntax' <atom-syntax@imc.org>, WebDAV <w3c-dist-auth@w3.org>
Message-id: <B0C85ABE-2C6D-4CFF-B6FD-CB7D8F329AF5@mac.com>
To: Julian Reschke <julian.reschke@gmx.de>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 November 2009 16:08:54 GMT