last-calling I-D Action:draft-brown-versioning-link-relations-03

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

last-calling I-D Action:draft-brown-versioning-link-relations-03

Julian Reschke
(FYI)

This update to yesterday's draft is purely editorial, moving each link
relation into a proper subsection, and using the correct IANA
registration template as defined per RFC 4287.

At this point we'd like to ask the community for final feedback; we are
planning to request publication in two weeks from now (Dec 04).

Best regards,

Julian


[hidden email] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title           : Link Relations for Simple Version Navigation
> Author(s)       : A. Brown, et al.
> Filename        : draft-brown-versioning-link-relations-03.txt
> Pages           : 11
> Date            : 2009-11-20
>
> This specification defines Atom link relations for navigation between
> a resource and its versions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
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

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
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
>


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
Jan Algermissen wrote:
> (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.

The reason for making the distinction is that in many systems, versions
and versionable resources are different things (for instance, in JCR and
WebDAV).

> '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).

The URI of a working copy may not be private at all.

...it's really to hard to come up with terminology that is compatible
with many different system.

> 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)

No, I'm listening; and hoping for more feedback...

BR, Julian

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Julian Reschke
Sam Johnston wrote:

> Julian et al,
>
> It's probably worth taking a look at
> draft-johnston-addressing-link-relations
> <http://tools.ietf.org/html/draft-johnston-addressing-link-relations-00>
> as well as it defines both "current" and "latest" as well as
> "canonical", "immutable", "mirror", "permalink" and my favourite,
> "shortlink". This has been adopted by Wordpress, Drupal & others with a
> view to bringing an end to third-party URL shortening services (the rust
> of the Internet).
>
> While I support link relations for versioning, I'd prefer to see
> relations for generic addressing requirements consolidated in one draft.
>
> Sam
> ...

Hi Sam,

I'm not convinced that throwing everything into a single document will
be helpful; draft-brown-versioning-link-relations tries to focus on a
small set of things, and, as Jan's feedback shows, it's non-trivial to
get even those things right.

Do you have any *specific* comments with respect to the relations that
it proposes?

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-2
In reply to this post by Julian Reschke

On Nov 26, 2009, at 4:26 PM, Julian Reschke wrote:

> Jan Algermissen wrote:
>> (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.
>
> The reason for making the distinction is that in many systems,  
> versions and versionable resources are different things (for  
> instance, in JCR and WebDAV).
>
>> '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).
>
> The URI of a working copy may not be private at all.
>
> ...it's really to hard to come up with terminology that is  
> compatible with many different system.

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

I have come to approach "hypermedia semantics" (media types, link  
relations, etc.) in terms of the goals they enable. Turning this  
around would mean: if something does not support a specific (probably  
very tiny) goal it should not be there.



Yes, versions and versionable resources can be different but is the  
distinction necessary for enabling the goals of the draft?

Stressing the point for analysis purposes:

"There is nothing a client cannot do when it does not understand the  
notion of 'versioned resource'".

Jan




>
>> 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)
>
> No, I'm listening; and hoping for more feedback...





>
> BR, Julian

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

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




Reply | Threaded
Open this post in threaded view
|

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

Geoffrey M Clemm
In reply to this post by Julian Reschke

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
> >
>
>
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Jan Algermissen-2
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.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Julian Reschke
Sam Johnston wrote:

> On Thu, Nov 26, 2009 at 4:30 PM, Julian Reschke <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Sam,
>
>     I'm not convinced that throwing everything into a single document
>     will be helpful; draft-brown-versioning-link-relations tries to
>     focus on a small set of things, and, as Jan's feedback shows, it's
>     non-trivial to get even those things right.
>
>
> I'm not suggesting throwing everything in one document - just keeping
> addressing (permalinks, shortlinks, etc.) separate from versioning. It
> may well make more sense to drop relations from
> draft-johnston-addressing-link-relations if they are more about
> versioning than addressing.

OK, thanks for clarifying.

>     Do you have any *specific* comments with respect to the relations
>     that it proposes?
>
>
> My first thoughts were that the relations themselves could be more concise:

I don't think that it's essential to make these short names even
shorter. The terms we currently use are in sync with some specs related
to versioning.

>     * version-history -> versions, history or revisions
>     * latest-version -> latest
>     * working-copy -> ok
>     * predecessor-version -> predecessor or previous-version or
>       prev-version (which is it, prev or previous - I think there's some
>       ambiguity here)
>     * successor-version -> successor or next-version

I think the suffix "-version" is important because there can be many
other similar relations providing "prex/next/last", which have nothing
to do with versioning.

> I also wonder whether it makes sense to offer links to "native" revision
> control (e.g. hg, git, svn, etc.) and/or web interfaces to them - and
> then specifics like branches and tags, and what a URI/URL to a
> branch/tag would even look like.

That's an interesting thought, but appears to be a much more complex
problem that the one we wanted to solve here.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-2
In reply to this post by Julian Reschke

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: [hidden email]
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------




Reply | Threaded
Open this post in threaded view
|

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

Geoffrey M Clemm
In reply to this post by Julian Reschke

Yes, once one goes to more advanced features (like branches and tags), it becomes harder to find or agree on common link types.
Note that RFC-3253 defines a full versioning protocol, including branches (called "activities") and tags (called "baselines).

Cheers,
Geoff

Julian Reschke wrote on 11/26/2009 10:58:37 AM:
> Sam Johnston wrote:
>  ...
> > I also wonder whether it makes sense to offer links to "native" revision
> > control (e.g. hg, git, svn, etc.) and/or web interfaces to them - and
> > then specifics like branches and tags, and what a URI/URL to a
> > branch/tag would even look like.
>
> That's an interesting thought, but appears to be a much more complex
> problem that the one we wanted to solve here.
>
> Best regards, Julian
>
Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-2
In reply to this post by Julian Reschke

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."
>

> 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


> 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: [hidden email]
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------




Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-2

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: [hidden email]
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>
>
>

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

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




Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Jan Algermissen-2
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."
>>
>
>> 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.
> ...

For now I have applied my change proposal in
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#rfc.section.2>,
but that doesn't mean we can't spend some more time with wordsmithing :-)

BR, Julian

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Jan Algermissen-2
Jan Algermissen wrote:

> 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
 >> ...

Hi Jan,

if I understand you correctly you say that the proposed text explaining
checkin/checkout should mention that it applies to modifying the working
copy. I believe that's correct, but would require a forward reference to
the term "working copy" that I'd like to avoid. (If you meant to say
something else, please clarify).

With respect to replacing

"Other servers allow modification, in which case the checkout/checkin
operation may happen implicitly."

by

"Other servers allow modification and perform versioning without
requiring an explicit checkout operation."

...: this really seems to be equivalent; any particular reason why you
feel your text is clearer?

Best regards, Julian





Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-2
Julian,

On Nov 27, 2009, at 3:56 PM, Julian Reschke wrote:

> Jan Algermissen wrote:
>> 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
> >> ...
>
> Hi Jan,
>
> if I understand you correctly you say that the proposed text  
> explaining checkin/checkout should mention that it applies to  
> modifying the working copy.

What I tried to say is that the notion of working-copy goes hand in  
hand with the notion of checking out. Or, to view it from a different  
angle: when a server is versioning, it can do so either implicitly (on  
its own) upon a modification of the resource that is being versioned  
by the server or it can require the user to do it explicitly by  
cheking out->working copy->update working copy->check-in. Without a  
notion of check-in the working-copy notion is useless because it will  
never lead to a new version.


> I believe that's correct, but would require a forward reference to  
> the term "working copy" that I'd like to avoid. (If you meant to say  
> something else, please clarify).
>

I think the notion of versioning is orthogonal to the notion of  
checkout/checkin and the draft seems to be centered around it. If a  
resource is being versioned by the server, all relations make sense,  
except working-copy. Only for working-copy you need to introduce  
checkin/checkout. It is just another means putting the versioning  
'action' in the hands of the client.

(But please takte this only as input - the draft just triggered an  
analysis process and that keeps going :-)
I cannot judge if it is significant enough to justify work on the  
draft or even this exchange...


> With respect to replacing
>
> "Other servers allow modification, in which case the checkout/
> checkin operation may happen implicitly."
>
> by
>
> "Other servers allow modification and perform versioning without  
> requiring an explicit checkout operation."
>
> ...: this really seems to be equivalent; any particular reason why  
> you feel your text is clearer?
>

The latter IMHO takes the focus away from checkin/checkout which I see  
as an absolute edge-case (being non DAV and
non CMIS biased :-)

But then....word smithing I guess.

Jan


> Best regards, Julian
>
>
>
>
>

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

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




Reply | Threaded
Open this post in threaded view
|

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

Geoffrey M Clemm

Note that versioning servers without working copies often still require a checkout/checkin protocol.
The "checkout" method is used as a notification to other users that this client is working on that resource.
The "checkin" method is used to tell the server "I want you to create a new version with the current content" (while a PUT just updates the current content without creating a new version).

Cheers,
Geoff

Jan Algermissen wrote on 11/27/2009 12:13:27 PM:

...
> I think the notion of versioning is orthogonal to the notion of  
> checkout/checkin and the draft seems to be centered around it. If a  
> resource is being versioned by the server, all relations make sense,  
> except working-copy. Only for working-copy you need to introduce  
> checkin/checkout. It is just another means putting the versioning  
> 'action' in the hands of the client.
>
> (But please takte this only as input - the draft just triggered an  
> analysis process and that keeps going :-)
> I cannot judge if it is significant enough to justify work on the  
> draft or even this exchange...
>

Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-2

On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:

>
> Note that versioning servers without working copies often still  
> require a checkout/checkin protocol.
> The "checkout" method is used as a notification to other users that  
> this client is working on that resource.
> The "checkin" method is used to tell the server "I want you to  
> create a new version with the current content" (while a PUT just  
> updates the current content without creating a new version).

In this case, checkout/checkin is also orthogonal to the notion of  
versioning and would not need to be mentioned in the spec. IOW, the  
only reason mentioning checkin/checkout in the spec is because the  
definition of working copy depends on it.

Jan


>
> Cheers,
> Geoff
>
> Jan Algermissen wrote on 11/27/2009 12:13:27 PM:
>
> ...
> > I think the notion of versioning is orthogonal to the notion of
> > checkout/checkin and the draft seems to be centered around it. If a
> > resource is being versioned by the server, all relations make sense,
> > except working-copy. Only for working-copy you need to introduce
> > checkin/checkout. It is just another means putting the versioning
> > 'action' in the hands of the client.
> >
> > (But please takte this only as input - the draft just triggered an
> > analysis process and that keeps going :-)
> > I cannot judge if it is significant enough to justify work on the
> > draft or even this exchange...
> >
>

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

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




Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
Jan Algermissen wrote:

>
> On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:
>
>>
>> Note that versioning servers without working copies often still
>> require a checkout/checkin protocol.
>> The "checkout" method is used as a notification to other users that
>> this client is working on that resource.
>> The "checkin" method is used to tell the server "I want you to create
>> a new version with the current content" (while a PUT just updates the
>> current content without creating a new version).
>
> In this case, checkout/checkin is also orthogonal to the notion of
> versioning and would not need to be mentioned in the spec. IOW, the only
> reason mentioning checkin/checkout in the spec is because the definition
> of working copy depends on it.
> ...

Does it?

"A "working copy" is a resource at a server-defined URL that can be
modified to create a new version of a versioned resource."

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-2

On Nov 30, 2009, at 1:02 PM, Julian Reschke wrote:

> Jan Algermissen wrote:
>> On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:
>>>
>>> Note that versioning servers without working copies often still  
>>> require a checkout/checkin protocol.
>>> The "checkout" method is used as a notification to other users  
>>> that this client is working on that resource.
>>> The "checkin" method is used to tell the server "I want you to  
>>> create a new version with the current content" (while a PUT just  
>>> updates the current content without creating a new version).
>> In this case, checkout/checkin is also orthogonal to the notion of  
>> versioning and would not need to be mentioned in the spec. IOW, the  
>> only reason mentioning checkin/checkout in the spec is because the  
>> definition of working copy depends on it.
>> ...
>
> Does it?
>
> "A "working copy" is a resource at a server-defined URL that can be  
> modified to create a new version of a versioned resource."
>

So it might be enough to:

PUT /working-copies/667

<foo/>

to create a new version of /main/667 ?? (assuming that /main/667 --
working-copy--> /working-copies/667)

What would be the reason to have a working copy that needs not be  
checked-in?

Jan






> Best regards, Julian

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

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




12