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

On Nov 26, 2009, at 2:29 PM, Julian Reschke wrote:

> Jan,
>
> here's my proposal for the checkin/checkout issue you raised (see <http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out 
> >):
>
> 1) Do not specify *how* to checkin/checkout; this really depends on  
> the protocol, and might not be the same for different AtomPub stacks  
> (and definitively not for WebDAV). However, the link relations that  
> we do defined are supposed to be general-purpose, and to be usable  
> outside the Atom space (in-line with Mark's "Web Linking" proposal).
>
> 2) For the definition of checkin/checkout and the point you raised,  
> how about changing the explanation of "versioned resource" from:
>
> "When a resource is put under version control, it becomes a  
> "versioned resource". A versioned resource can be "checked out" to  
> allow modification."
>
> to
>
> "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 go back to the "checked-in" state. Other servers allow  
> modification, in which case the checkout/checkin operation may  
> happen implicitly."
>

(Sorry if this is confusing matters, but...)
I am not sure that the notion of a 'versioned resource' is necessary  
at all. If the draft defined 'version' instead the whole checkin/ 
checkout notion could be dropped.

'Working Copy' could be defined separately as a resource that is an  
'private copy' of a resource, one whose URI is not made available to  
any client except upon initial creation (sorry that this is so  
imprecise - I hope you get the idea).

IWO, the draft somehow circles around the checkin/checkout operations  
and I am not sure that is necessary.

(But if this sounds completely insane, just ignore it)


Jan





> Best regards, Julian
>
>
>
> Julian Reschke wrote:
>> Hi Jan,
>> first of all thanks for the feedback!
>> Jan Algermissen wrote:
>>> Julian,
>>>
>>> some comments on the link relation draft:
>>>
>> > 2. Terminology
>>>
>>> It is not clear to me, what the meaning of 'check out' and 'check  
>>> in'.
>> Yes, we need to add text here. We originally started with the  
>> definitions with RFC 3253 (WebDAV versioning), but later on decided  
>> later on to just rely on generic definitions to make this work  
>> better with CMIS and JCR.
>>> Also, the text (IMO) creates the impression that versioning can  
>>> only take place when 'check out' and 'check in' are applied.  
>>> However, a resource could also be versioned by the server upon any  
>>> modification made by a client regardless of any 'checking out' or  
>>> 'checking in'. The link relations specified would still make sense.
>> Indeed; and that's something that can even happen in WebDAV  
>> versioning (through the various modes of auto-versioning).
>>> Assuming that 'checking out' and 'checking in' are operations on  
>>> resources, I think the draft should address how clients achieve  
>>> these operations. This would at least involve another link  
>>> relation and specification how to use the linked resource to  
>>> perform a checkout.
>> These kinds of operations are specific to the protocol in which  
>> they are used, while the link relations are meant to be generic;  
>> thus I'd avoid to go that way.
>> For now, I've added this to the issues list: <http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out 
>> >. I'll try to make a change proposal soonish.
>>> Or am I misunderstanding what the draft is trying to do?
>>>
>>> Appendix A
>>>
>>> It should be 'working-copy' instead of 'working-resource'.
>> Indeed. Thanks for catching this.
>>> I am glad to see this happening. Covers a lot of stuff that comes  
>>> up in almost every project. Thanks.
>> That's good to hear, because defining generic link relations  
>> doesn't make sense unless there are generic use cases for them :-)
>> Best regards, Julian
>

--------------------------------------
Jan Algermissen

Mail: [email protected]
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------