On Nov 26, 2009, at 5:21 PM, Jan Algermissen wrote:
On Nov 26, 2009, at 2:29 PM, Julian Reschke wrote:
"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."
Forgot to insert:
What about:
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 and perfrom versioning without requiring an explicit
checkout operation.
I feel there should be the notion of 'modification of checked-out
working copy' in there but I don't mean to say that your above
wording isn't suitable also.
Jan
Sorry,
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
--------------------------------------
--------------------------------------
Jan Algermissen
Mail: [email protected]
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------
