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

I like Julian's proposed wording.  It accurately captures the two main 
alternatives: an explicit checkout/checkin required and an implicit 
checkout/checkin on write.  (Note that WebDAV/DeltaV supports both of 
these models).

Cheers,
Geoff

Julian Reschke  wrote on 11/26/2009 08:29:40 AM:
> 
> 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."
> 
> 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
> > 
> 
>