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

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Dec 2009 14:27:40 +0100

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

To make things cleared, I have added a short pointer to the Introduction:

"These link relations are used in the AtomPub ([RFC5023]) bindings of 
the "Content Management Interoperability Services" (CMIS). See Section 
3.4.3.1 of [CMIS] for further information." -- 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#introduction>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Dec 2009 14:27:40 +0100

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Dec 2009 15:07:52 +0100

Jan Algermissen wrote:
> ...
> Hmm, I think so. The definition in a sense implies that the version is 
> created as a result of the modification. Which is IMHO *never* the case 
> for working copies.
> 
> Surely the draft must define 'working copy'. What is the nature of a 
> working copy? What is its true nature? I think: being *used* for 
> creating new versions. So, what about:
> 
>>>> "A "working copy" is a resource at a server-defined URL that can be 
>>>> *used* to create a new version of a versioned resource."
> ...

So, substituting "modified" by "used". I'm ok with that.

> and remove checkout/checkin completely. ('use' instead of 'modify' 
> sounds less like "The modification cause the versioning" (which it never 
> does by nature of a working copy (IMHO - s.a.))
> 
> If the draft wanted to define it, then it woud be something like:
> 
> checkout: an operation on a resource that creates a working copy
> checkin: an operation on a working copy that creates a new version of 
> its corresponding versioned resource.

The issue here is that in some systems, checkout will not create a new 
resource, just flip a bit on the versioned resource.

Also, (I think) there are systems where checking in does not create a 
new version, but flips a bit on the working resource *making* it a 
version (at the same URL).

Thus, defining this would need to be defined in a more generic way. My 
attempt:

"Checkout: an operation on a versioned resource that creates a working 
copy, or changes the versioned resource to be a working-copy as well 
("in-place versioning").

Checkin: an operation on a working copy that creates a new version of
its corresponding versioned resource.

Note: the operations for putting a resource under version control, and 
for checking in and checking out depend on the protocol in use and are 
beyond the scope of this document; see [CMIS], [RFC3253] and [JSR-283] 
for details)."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Dec 2009 15:07:52 +0100

Best regards, Julian

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 02 Dec 2009 00:45:05 +0100

On Thu, 26 Nov 2009 16:58:37 +0100, Julian Reschke <[email-masked]>  
wrote:

> Sam Johnston wrote:
>
>>     * 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.

As long as the words "previous", "next" and "last" aren't used, there's no  
collision. "predecessor" and "successor" are pretty unambiguous and don't  
collide with any existing link relations that I'm aware of. Also, in this  
context (talking about documents) what else than "an earlier version"  
might you refer to when pointing to a "predecessor"?

In other words; I agree with Sam. I think the shorter and more concise  
relations are better. Either use words that don't imply "version" (like  
"previous" and "next") and suffix them with "-version" or use words that  
unambiguously refer to "versions" and have no suffix, but not a mix of  
both.

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

I think such problems are important to explore, since this I-D is  
something these SCM's might want to implement.

-- 
Asbjørn Ulsberg         -=|=-          [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 02 Dec 2009 07:41:56 +0100

Julian,

On Dec 1, 2009, at 3:07 PM, Julian Reschke wrote:

> Jan Algermissen wrote:
>> ...
>> Hmm, I think so. The definition in a sense implies that the version  
>> is created as a result of the modification. Which is IMHO *never*  
>> the case for working copies.
>> Surely the draft must define 'working copy'. What is the nature of  
>> a working copy? What is its true nature? I think: being *used* for  
>>>>> "A "working copy" is a resource at a server-defined URL that can  
>>>>> be *used* to create a new version of a versioned resource."
>> ...
>

Fine.

>> sounds less like "The modification cause the versioning" (which it  
>> never does by nature of a working copy (IMHO - s.a.))
>> checkin: an operation on a working copy that creates a new version  
>> of its corresponding versioned resource.
>
> The issue here is that in some systems, checkout will not create a  
> new resource, just flip a bit on the versioned resource.
>
> Also, (I think) there are systems where checking in does not create  
> a new version, but flips a bit on the working resource *making* it a  
> Thus, defining this would need to be defined in a more generic way.  
> My attempt:
>
> "Checkout: an operation on a versioned resource that creates a  
> working copy, or changes the versioned resource to be a working-copy  
> as well ("in-place versioning").
>
> Note: the operations for putting a resource under version control,  
> and for checking in and checking out depend on the protocol in use  
> and are beyond the scope of this document; see [CMIS], [RFC3253] and  
> [JSR-283] for details)."

Sounds good to me.

Jan

> Best regards, Julian

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

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

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 02 Dec 2009 07:41:56 +0100

Julian,

Fine.

Sounds good to me.

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 02 Dec 2009 11:56:47 +0100

Julian,

what is your opinion regarding the introduction of a link relation  
that is the opposite of working-copy in order to being able to find  
the versioned resource that the working copy I have is a working copy  
of?

I am undecided regarding the necessity, but without a working-copy-of  
relation it seems the client would need to maintain that information  
(the relationship or the fact that a given resource is a working copy)  
across requests.

I do not think this is really I-D publication relevant right now,  
please understand it only as a side comment.

Jan

On Nov 20, 2009, at 3:13 PM, Julian Reschke wrote:

>
> (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
>
>
> [email-masked] 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
>> [email-masked]
>> 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
>

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 02 Dec 2009 11:56:47 +0100

Julian,

Jan

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Dec 2009 16:55:19 +0100

Asbjørn Ulsberg wrote:
> 
> On Thu, 26 Nov 2009 16:58:37 +0100, Julian Reschke 
> <[email-masked]> wrote:
> 
>> Sam Johnston wrote:
>>
> As long as the words "previous", "next" and "last" aren't used, there's 
> no collision. "predecessor" and "successor" are pretty unambiguous and 
> don't collide with any existing link relations that I'm aware of. Also, 

They do not collide with link relations, but they aren't unambiguous 
either. For instance, <http://www.imdb.com/title/tt0071562/> is the 
successor of <http://www.imdb.com/title/tt0068646/>, but it's not a 
successor version.

> in this context (talking about documents) what else than "an earlier 
> version" might you refer to when pointing to a "predecessor"?
> 

Not convinced. I'll leave this to the expert review and the IESG.

>>> them - and then specifics like branches and tags, and what a URI/URL 
>>> to a branch/tag would even look like.
>>

I agree that it's an interesting problem, but just because something is 
interesting doesn't mean it needs to be solved in this proposal. At this 
point, I'd rather take out things than add new things.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Dec 2009 16:55:19 +0100

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Dec 2009 17:58:56 +0100

Jan Algermissen wrote:
> Julian,
> 
> what is your opinion regarding the introduction of a link relation that 
> is the opposite of working-copy in order to being able to find the 
> versioned resource that the working copy I have is a working copy of?
> 
> I do not think this is really I-D publication relevant right now, please 
> understand it only as a side comment.
> ...

I have no problems adding this; the reason it hasn't been proposed was 
that apparently CMIS didn't have a use case for it.

Al, any opinion on this from a CMIS point of view?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Dec 2009 17:58:56 +0100

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Dec 2009 18:59:01 +0100

Jan Algermissen wrote:
>>> is created as a result of the modification. Which is IMHO *never* the 
>>> case for working copies.

OK, I have added the text as proposed in my copy at 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html>, 
the terminology section now reads:

    Versioned Resource

       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 get back to the "checked-in" state.  Other
       servers allow modification, in which case the checkout/checkin
       operation may happen implicitly.

    Version History

       A "version history" resource is a resource that contains all the
       versions of a particular versioned resource.

    Predecessor, Successor

       When a versioned resource is checked out and then subsequently
       checked in, the version that was checked out becomes a
       "predecessor" of the version created by the checkin.  A client can
       specify multiple predecessors for a new version if the new version
       is logically a merge of those predecessors.  The inverse of the
       predecessor relation is the "successor" relation.  Therefore, if X
       is a predecessor of Y, then Y is a successor of X.

    Working Copy

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

    Checkin

       A "checkin" is an operation on a versioned resource that creates a
       working copy, or changes the versioned resource to be a working-
       copy as well ("in-place versioning").

    Checkout

       A "checkout" is an operation on a working copy that creates a new
       version of its corresponding versioned resource.

       Note: the operations for putting a resource under version control,
       and for checking in and checking out depend on the protocol in use
       and are beyond the scope of this document; see [CMIS], [RFC3253]
       and [JSR-283] for examples.

...as always, feedback appreciated,

Julian

---

From: Al Brown <[email-masked]>
Date: Wed, 2 Dec 2009 09:48:13 -0800

Jan I appreciate all your help on this.

It's an interesting concept.  I would have used predecessor-version to
specify the version that the working copy came from.  This does not work as
well in some systems that as mentioned creates a new version on checkin
rather than checkout.  In those systems the working copy and the version
the working copy came from are internally in that system the same.

I am okay with adding it.  It makes sense.  It reduces the overload on the
predecessor-version.  CMIS (and any other system) can leverage the new link
relation if desired.

-Al

Al Brown
Office 714 327 3453
Mobile 714 251 6441
Email  [email-masked]
CONFIDENTIAL NOTICE: The contents of this message, including any
attachments, are confidential and are intended solely for the use of the
person or entity to whom the message was addressed. If you are not the
intended recipient of this message, please be advised that any
dissemination, distribution, or use of the contents of this message is
strictly prohibited. If you received this message in error, please notify
the sender. Please also permanently delete all copies of the original
message and any attached documentation.

From:	Julian Reschke <[email-masked]>
To:	Jan Algermissen <[email-masked]>
Cc:	"Atom-syntax Syntax'" <[email-masked]>, WebDAV
            <[email-masked]>, Al Brown/Costa Mesa/IBM@IBMUS
Date:	12/02/2009 09:07 AM
Subject:	Re: (Opposite of working-copy?) Comment on
            draft-brown-versioning-link-relations-03
Sent by:	[email-masked]

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Dec 2009 18:59:01 +0100

Versioned Resource

    Version History

    Predecessor, Successor

    Working Copy

    Checkin

    Checkout

Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Dec 2009 15:17:35 +0100

Julian Reschke wrote:
>> the versioned resource that the working copy I have is a working copy of?
>>

OK, I have added working-copy-of, and plan to submit the current draft 
(also including the other changes we discussed) as 
draft-brown-versioning-link-relations-04 later today.

A marked up version with diffs is available at
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html>, 
feedback appreciated.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Dec 2009 15:17:35 +0100

Best regards, Julian